DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the amendments filed on 2/26/2026, wherein:
Claim 1 has been amended;
Claims 2-8 have been cancelled; and
Claim 1 is currently pending and has been examined.
Specification
Applicant’s 2/26/2026 amendments to the specification are accepted by the Examiner.
Drawing Objection Specification
Applicant’s replacement drawing sheets filed on 2/26/2026 are accepted by the examiner and the previous drawing objections are withdrawn.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention to which it pertains, or with which it is most nearly connected, to make and/or use the invention. The following claimed limitations are recited within the specification without provision for any structural details or any explanation of their meaning such that one of ordinary skill in the art would not know how to configure a design method for a UAS:
Claim 1 includes the limitations “the method being performed by an electric device comprising a processor and a memory having instructions stored thereon, wherein the memory further stores a SysML logical model and a Modelica mathematical model, when the processor executes the program instructions stored in the memory, the processor is configured to perform following operations”. However, the drawings, original claims, and specification do not provide a written description disclosure to support the claimed limitations of “the method being performed by an electric device comprising a processor and a memory having instructions stored thereon, wherein the memory further stores a SysML logical model and a Modelica mathematical model, when the processor executes the program instructions stored in the memory, the processor is configured to perform following operations”, and there is no mention of these claimed limitations anywhere in the original specification, original claims, or drawings. At best, the drawings, original claims, and specification vaguely and generically describes establishing an architecture development framework for an unmanned aerial vehicle system.
Regarding Claim 1, the claim recites “step 1: establishing an architecture development framework of the UAS, comprising: defining viewpoints of concern in a UAS architecture design process and views to be developed in each viewpoint”. The specification does not provide adequate written description of how to: establish the architecture development framework of the UAS, define viewpoints of concern…, and viewpoints to be developed in each viewpoint. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes establishing an architecture development framework for an unmanned aerial vehicle system. There is no description of what the steps/procedure actually entail or what technology is used implement the claimed steps of the method for designing the UAS. They are simply treated as labeled blocks on various diagrams. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The specification does not at all describe the steps/procedure involved in the viewpoints of concern. Clearly the written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for “establishing an architecture development framework of the UAS, comprising: defining viewpoints of concern in a UAS architecture design process and views to be developed in each viewpoint”.
Regarding Claim 1, the claim recites “step 2: designing a development process of the UAS from an operational viewpoint, developing a logical model and spatio-temporal model of UAS operation according to an input UAS operational concept, carrying out simulation of a system of systems model, verifying rationality of the system of systems model, and generating operational requirements”. The specification does not provide adequate written description of how to: design a UAS development process from an operational viewpoint, develop a logical model and spatio-temporal model…, carry out simulation…, and verify rationality…, and generate operational requirements. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes: designing a development process of the UAS from an operational viewpoint, developing a logical model and spatio-temporal model of UAS operation according to an input UAS operational concept, carrying out simulation of a system of systems model, verifying rationality of the system of systems model, and generating operational requirements. There is no description of what each of the steps/procedures actually entail or what technology is used implement the claimed limitations of step 2 of the design method for the UAS. They are simply treated as labeled blocks on the various diagrams. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The specification does not at all describe the steps/procedure involved in step 2 of the method. Clearly the written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for “designing a development process of the UAS from an operational viewpoint, developing a logical model and spatio-temporal model of UAS operation according to an input UAS operational concept, carrying out simulation of a system of systems model, verifying rationality of the system of systems model, and generating operational requirements”.
Regarding Claim 1, the claim recites “step 3: designing a development process of the UAS from a logical viewpoint, developing a logical model and geometric model of the UAS itself according to input UAS operational requirements, carrying out simulation of a system model, verifying rationality of the system model, and generating system requirements”. The specification does not provide adequate written description of how to: design a UAS development process from a logical viewpoint, develop a logical model and geometric model…, carry out simulation…, verify rationality…, and generate system requirements. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes: developing a logical and geometric model, carrying out simulation, verifying rationality and generating system requirements. There is no description of what each of the steps/procedures actually entail or what technology is used implement the claimed limitations of step 3 of the design method for the UAS. They are simply treated as labeled blocks on the various diagrams. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The specification does not at all describe the steps/procedure involved in step 3 of the method. Clearly the written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for “designing a development process of the UAS from a logical viewpoint, developing a logical model and geometric model of the UAS itself according to input UAS operational requirements, carrying out simulation of a system model, verifying rationality of the system model, and generating system requirements”.
Regarding Claim 1, the claim recites “step 4: designing a development process of the UAS from a physical viewpoint, developing a logical model and mathematical model of components of the UAS according to input UAS requirements, carrying out simulation of a component model, verifying rationality of the component model, and generating component requirements”. The specification does not provide adequate written description of how to: design a UAS development process from a physical viewpoint, develop a logical model and mathematical model…, carry out simulation…, and verify rationality…, and generate component requirements. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes: designing a development process of the UAS from a physical viewpoint, developing a logical model and mathematical model of UAS components according to an input UAS operational concept, carrying out simulation of the components model, verifying rationality of the component model, and generating component requirements. There is no description of what each of the steps/procedures actually entail or what technology is used implement the claimed limitations of step 4 of the design method for the UAS. They are simply treated as labeled blocks on the various diagrams. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The specification does not at all describe the steps/procedure involved in step 4 of the method. Clearly the written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for “designing a development process of the UAS from a physical viewpoint, developing a logical model and mathematical model of components of the UAS according to input UAS requirements, carrying out simulation of a component model, verifying rationality of the component model, and generating component requirements”.
Regarding Claim 1, the claim recites “step 5: carrying out integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint, so as to realize multi-domain, multi-dimensional, and multi-disciplinary UAS architecture simulation, and carry out closed-loop verification of the operational requirements, the system requirements, and the component requirements of the UAS to obtain component parameters”. The specification does not provide adequate written description of how to: carry out integration of the models from any of the claimed viewpoints to realize the claimed simulation, or to carry out closed-loop verification of the requirements of the UAS to obtain component parameters. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes: carrying out integration of the models from the viewpoints, realizing architecture simulation, and component requirements. There is no description of what each of the steps/procedures actually entail or what technology is used implement the claimed limitations of step 5 of the design method for the UAS. They are simply treated as labeled blocks on the various diagrams. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The specification does not at all describe the steps/procedure involved in step 5 of the method. Clearly the written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for “carrying out integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint, so as to realize multi-domain, multi-dimensional, and multi-disciplinary UAS architecture simulation, and carry out closed-loop verification of the operational requirements, the system requirements, and the component requirements of the UAS to obtain component parameters”.
Regarding Claim 1, the claim recites “step 6: generating based on the obtained component parameters, physical specifications and physical interfaces for components of the UAS, and recording the physical specifications and physical interfaces using SysML instance specification bloc definition diagrams”. The specification does not provide adequate written description of how to: generate based on the obtained information or recording the specifications and interfaces. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes: a cyber-physical model that is co-simulated to verify design. There is no description of what each of the steps/procedures actually entail for generating and recording or what technology is used implement the claimed limitations of step 6. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The specification does not at all describe the steps/procedure involved in step 6 of the method. Clearly the written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for “constructing the UAS based on the obtained component parameters”.
Claimed limitations in claim 1 for: “wherein in step 2, the development process of the UAS from the operational viewpoint comprises the following activities: (1) from a viewpoint of UAS operation, analyzing description of the operational concept provided by a user, transforming the operational concept into itemized operational requirements, and using an SysML requirement diagram for expression; (2) identifying relevant operational nodes from the operational requirements, and using an SysML block definition diagram for expression; (3) identifying main operational tasks from the operational requirements, and using an SysML use case diagram for expression; (4) defining operational activities for each operational task, as well as a control flow and an object flow between the operational activities, and assigning these activities to different swimlanes, using an SysML activity diagram for expression, wherein each swimlane is associated with the operational node; (5) defining conceptual data used in the system of systems model by analyzing the object flow in the operational activities, and using an SysML block definition diagram for expression; wherein the development process of the UAS from the operational viewpoint further comprises the following activities: based on activities (4) and (5), defining synchronous or asynchronous messages transferred between the operational nodes, and using an SysML sequence diagram for expression (6) based on activities (4) and (5), transforming the control flow and object flow between different swimlanes into operation ports between the operational nodes, defining the conceptual data transferred in the operation ports, and using an SysML internal block diagram for expression; (7) analyzing a state that the operational node is capable of maintaining for a long time, associating the state with the operational activities assigned to the operational node in the swimlane, defining a state transition logic of the operational node, and using an SysML state machine diagram for expression; and (8) defining a measure of effectiveness (MOE) of the operational concept and a key performance parameter (KPP) of the operational node, establishing a constraint relationship between a MOE and the KPP, and using an SysML parametric diagram for expression;” are not described in the drawings or specification with: adequate definitions, adequate written descriptions of how to conduct any of these claimed activities for step 2, or what technology and hardware are used to implement the claimed activities The specification does not describe how the messages are defined or transferred between operating nodes or for how a SysML sequence diagram is used for expression.
Claimed limitations in claim 1 for: “wherein in step 3, the development process of the UAS from the logical viewpoint comprises the following activities:(1) from a viewpoint of UAS designers, transforming the operational requirements assigned to operational nodes of the UAS into technical requirements of the UAS, and using an SysML requirement diagram for expression; (2) based on operational activities assigned to the operational nodes of the UAS, decomposing the operational activities into top-level functions of the UAS, and using an SysML use case diagram for expression; (3) based on the top-level functions of the UAS, decomposing and analyzing system functions with domain knowledge, assigning the functions to different swimlanes, and using an SysML activity diagram for expression; (4) defining internal components of the UAS by analyzing the swimlanes in the system activity diagram, and using an SysML block definition diagram for expression; (5) defining logical data of the system by analyzing a control flow and an object flow between the swimlanes in system activities, and using an SysML block definition diagram for expression; wherein the development process of the UAS from the logical viewpoint further comprises the following activities: based on activities (4) and (5), defining synchronous or asynchronous messages transferred between the operational nodes, and using an SysML sequence diagram for expression; (6) based on activities (4) and (5), transforming the control flow and the object flow between different swimlanes into logical ports between system elements, defining the logical data transferred in the logical ports, and using an SysML internal block diagram for expression; (7) analyzing a state that the system element is capable of maintaining for a long time, associating the state with the system activities assigned to the system element in the swimlane, defining a state transition logic of the system element, and using an SysML state machine diagram for expression; and (8) transforming a KPP assigned to the operational nodes of the UAS into a measure of performance (MOP) of the UAS, establishing a constraint relationship between the MOP of the UAS and an MOP of the system element, and using an SysML parametric diagram for expression” are not described in the drawings or specification with: adequate definitions, adequate written descriptions of how to conduct any of these claimed activities for step 3, or what technology and hardware are used to implement the claimed activities. The specification also does not provide: adequate written description of how the messages are defined or transferred between operating nodes or for how a SysML sequence diagram is used for expression
Claimed limitations in claim 1 for: “wherein in step 4, the development process of the UAS from the physical viewpoint comprises the following activities: (1) based on transformation standards of SysML and Modelica, transforming a hierarchical structure and a cross-linking relationship in a UAS model into a cyber-physical model of the UAS; (2) ensuring that the Modelica-based cyber-physical model of the UAS and an SysML-based system description model have a same level, composition, and interface relationship, and developing a cyber-physical model of the components of the UAS with disciplinary knowledge; (3) based on an idea of componentized design, integrating a UAS component model containing multiple disciplines into a rapid prototype of the UAS from the bottom up according to the system level, composition, and interface relationship; (4) by using a non-causal Modelica solver, carrying out multi-disciplinary co-simulation to verify feasibility of MOPs of the system and a system element; (5) passing down design parameters verified by simulation as physical specifications, and using instance specification block definition diagrams in SysML for description; and (6) describing a physical interface and physical data involved in the physical specifications with the instance specification block definition diagrams in SysML” are not described in the drawings or specification with: adequate definitions, adequate written descriptions of how to conduct any of these claimed activities for step 4, or what technology and hardware are used to implement the claimed activities.
Claimed limitations in claim 1 for: “wherein in step 5, integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint is carried out, and the three interfaces involved for integrated development comprises: (1) a spatio-temporal-logical interface: the spatio-temporal-logical interface mainly obtains event, signal, position, and distance data from the spatio-temporal model, and triggers execution of operational behaviors in the logical model, and the logical model drives simulation of the spatio-temporal model according to an operational logic and operational rules; (2) a logical-mathematical interface: the logical-mathematical interface mainly realizes transformation of structure, data, and interface between the logical model and the mathematical model, the logical model transfers a system architecture and metric constraints to the mathematical model, and the mathematical model feeds back solution results and physical parameters to the logical model; and (3) a mathematical spatio-temporal interface: the mathematical -spatio-temporal interface drives transformation of temporal and spatial information in the spatio-temporal model mainly based on real-time solution results of the mathematical model, thereby generating new events, signals, positions, and distances” are not described in the drawings or specification with: adequate definitions, adequate written descriptions of how to conduct any of these claimed activities for step 5, or what technology and hardware are used to implement the claimed activities.
The rejections that follow are interpreted in light of the 35 USC 112 rejections discussed above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites limitations for: “defining viewpoints of concern…and views to be developed in each viewpoint”, “designing a development process of the UAS from an operational viewpoint”, “developing a logical model and spatio-temporal model of UAS operation…”, “carrying out simulation…”, “verifying rationality of the system of systems model”, “generating operational requirements”, “designing a development process of the UAS from a logical viewpoint”, “developing a logical model and geometric model…”, “designing a development process of the UAS from a physical viewpoint”, “developing a logical model and mathematical model of components…”, “carrying out integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint, so as to realize multi-domain, multi-dimensional, and multi-disciplinary UAS architecture simulation”, “carry out closed-loop verification of the operational requirements, the system requirements, and the component requirements of the UAS to obtain component parameters”, and “constructing the UAS based on the obtained component parameters”. The limitations are indefinite because it is unclear what makes up the claimed steps and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
Claim 1 recites limitations for “operational viewpoint”, the “logical viewpoint”, “the physical viewpoint”; “logical models”, “simulation models”, “mathematical models”, “spatio-temporal models”; “operational requirements”, “operational requirement traceability”, “operational nodes”, “operational interactions”, “operational actors”, “operational tasks”, “operational activities”, “operational states”, “conceptual data”, “effectiveness constraints”, “spatio-temporal information models; “ system requirements”, “system requirement traceability”, “system composition”, “system interactions”, “system actors”, “system functions”, “system activities”, “system states”, “logical data”, “performance constraints”, “system geometric models”; “physical specifications”, “physical interfaces”, “physical data”, “cyber-physical models”. The limitations are indefinite because it is unclear what makes up the claimed steps and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
Claim 1 recites limitations for “analyzing description of the operational concept provided by a user”, “transforming the operational concept into itemized operational requirements”, “using an SysML requirement diagram for expression”; “identifying relevant operational nodes from the operational requirements”, “using an SysML block definition diagram for expression”, “identifying main operational tasks from the operational requirements”, “using an SysML use case diagram for expression”, “defining operational activities for each operational task, as well as a control flow and an object flow between the operational activities”, “assigning these activities to different swimlanes”, “using an SysML activity diagram for expression”, “wherein each swimlane is associated with the operational node”; “defining conceptual data used in the system of systems model by analyzing the object flow in the operational activities”, “using an SysML block definition diagram for expression”; “transforming the control flow and object flow between different swimlanes into operation ports between the operational nodes”, “defining the conceptual data transferred in the operation ports”, “using an SysML internal block diagram for expression”; “analyzing a state that the operational node is capable of maintaining for a long time”, “associating the state with the operational activities assigned to the operational node in the swimlane”, “defining a state transition logic of the operational node”, “using an SysML state machine diagram for expression”; “defining a measure of effectiveness (MOE) of the operational concept and a key performance parameter (KPP) of the operational node”, “establishing a constraint relationship between the MOE and the KPP”, “using an SysML parametric diagram for expression”. The limitations are indefinite because it is unclear what makes up the claimed steps and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
Claim 1 recites limitations for “defining synchronous or asynchronous messages transferred between the operational nodes”, and “using an SysML sequence diagram for expression”. The limitations are indefinite because it is unclear what makes up the claimed activities and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
Claim 1 recites limitations for “from a viewpoint of UAS designers, transforming the operational requirements assigned to operational nodes of the UAS into technical requirements of the UAS”, “using an SysML requirement diagram for expression”, “based on operational activities assigned to the operational nodes of the UAS, decomposing the operational activities into top-level functions of the UAS”, “using an SysML use case diagram for expression”, “based on the top-level functions of the UAS, decomposing and analyzing system functions with domain knowledge”, “assigning the functions to different swimlanes”, “using an SysML activity diagram for expression”; “defining internal components of the UAS by analyzing the swimlanes in the system activity diagram”, “using an SysML block definition diagram for expression”; “defining logical data of the system by analyzing a control flow and an object flow between the swimlanes in system activities”, “using an SysML block definition diagram for expression”; “transforming the control flow and the object flow between different swimlanes into logical ports between system elements”, “defining the logical data transferred in the logical ports”, “using an SysML internal block diagram for expression”; “analyzing a state that the system element is capable of maintaining for a long time”, “associating the state with the system activities assigned to the system element in the swimlane”, “defining a state transition logic of the system element”, “using an SysML state machine diagram for expression”, “transforming a KPP assigned to the operational nodes of the UAS into a measure of performance (MOP) of the UAS”, “establishing a constraint relationship between the MOP of the UAS and an MOP of the system element”, and “using an SysML parametric diagram for expression”. The limitations are indefinite because it is unclear what makes up the claimed activities of step 3 and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
Claim 1 recites limitations for “based on transformation standards of SysML and Modelica, transforming a hierarchical structure and a cross-linking relationship in a UAS model into a cyber-physical model of the UAS”; “ensuring that the Modelica-based cyber-physical model of the UAS and an SysML-based system description model have a same level, composition, and interface relationship”, “developing a cyber-physical model of the components of the UAS with disciplinary knowledge”; “based on an idea of componentized design, integrating a UAS component model containing multiple disciplines into a rapid prototype of the UAS from the bottom up according to the system level, composition, and interface relationship”, “using a non-causal Modelica solver”, “carrying out multi-disciplinary co-simulation to verify feasibility of MOPs of the system and a system element”, “passing down design parameters verified by simulation as physical specifications”, “using instance specification block definition diagrams in SysML for description”, and “describing a physical interface and physical data involved in the physical specifications with the instance specification block definition diagrams in SysML”. The limitations are indefinite because it is unclear what makes up the claimed activities of step 4 and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
Claim 1 recites limitations for “integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint is carried out”, “the spatio-temporal-logical interface mainly obtains event, signal, position, and distance data from the spatio-temporal model”, “triggers execution of operational behaviors in the logical model”, “the logical model drives simulation of the spatio-temporal model according to an operational logic and operational rules”; “a logical-mathematical interface mainly realizes transformation of structure, data, and interface between the logical model and the mathematical model”, “the logical model transfers a system architecture and metric constraints to the mathematical model”, “the mathematical model feeds back solution results and physical parameters to the logical model”; and “a mathematical-spatio-temporal interface drives transformation of temporal and spatial information in the spatio-temporal model mainly based on real-time solution results of the mathematical model, thereby generating new events, signals, positions, and distances”. The limitations are indefinite because it is unclear what makes up the claimed activities of step 5 and it is also unclear what the limitations are referring to. These terms are not defined in the specification. It is also unknown what technology is used to implement the claimed steps because the specification does not specify any hardware or software for performing the method.
The rejections that follow are interpreted in light of the 35 USC 112 rejections discussed above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a method for designing an unmanned aerial vehicle which is considered a judicial exception because it falls under: Mental Processes and/or Certain Methods of Organizing Human Activity such as commercial or legal interactions, including marketing or sales activities or behaviors. This judicial exception is not integrated into a practical application as discussed below and the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as discussed below.
This rejection follows the 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed Reg 4, January 7, 2019, pp. 50-57 (“2019 PEG”)(MPEP 2106).
Analysis
Step 1 (Statutory Categories) – 2019 PEG pg. 53 (See MPEP 2106.03)
Claim 1 is directed to the statutory category of a process, machine, or manufacture.
Step 2A, Prong 1 (Do the claims recite an abstract idea?) – 2019 PEG pg. 54 (See MPEP 2106.04(a)-(c))
For independent claim 1, the claim recites an abstract idea of: designing an unmanned aerial vehicle. The steps of independent claim 1 recite the abstract idea (in bold below) of: “A model-based architecture design method for an unmanned aerial vehicle system (UAS), the method being performed by an electric device comprising a processor and a memory having program instructions store, wherein the memory further stores a SysML logical model and a Modelica mathematical model, when the processor executes the program instructions stored on the memory, the processor is configured to perform the following operations comprising: step 1: establishing an architecture development framework of the UAS, comprising: defining viewpoints of concern in a UAS architecture design process and views to be developed in each viewpoint; step 2: designing a development process of the UAS from an operational viewpoint, developing a logical model and spatio-temporal model of UAS operation according to an input UAS operational concept, carrying out simulation of a system of systems model, verifying rationality of the system of systems model, and generating operational requirements; step 3: designing a development process of the UAS from a logical viewpoint, developing a logical model and geometric model of the UAS itself according to input UAS operational requirements, carrying out simulation of a system model, verifying rationality of the system model, and generating system requirements; step 4: designing a development process of the UAS from a physical viewpoint, developing a logical model and mathematical model of components of the UAS according to input UAS requirements, carrying out simulation of a component model, verifying rationality of the component model, and generating component requirements; and step 5: carrying out integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint, so as to realize multi-domain, multi-dimensional, and multi-disciplinary UAS architecture simulation, and carry out closed-loop verification of the operational requirements, the system requirements, and the component requirements of the UAS to obtain component parameters; step 6: generating, based on the obtained component parameters, physical specification and physical interfaces for components of the UAS, and recording the physical specifications and the physical interfaces using SysML instance specification block definition diagrams; wherein in step 1, 3 viewpoints and 26 views are defined; and the 3 viewpoints comprise the operational viewpoint, the logical viewpoint, and the physical viewpoint; the operational viewpoint and the logical viewpoint are divided into 5 categories and 22 views according to requirements, structures, behaviors, constraints, data, and simulation, and the physical viewpoint is divided into 3 categories and 4 views according to product, data, and simulation; and requirement, structure, behavior, constraint, and data-type models in the operational and logical viewpoints, and product and data-type models in the physical viewpoint belong to logical models, simulation models in the three viewpoints belong to mathematical models, and due to time and space characteristics, the spatio-temporal information model and the system geometric model are subsumed to spatio-temporal models; the views contained in the above operational viewpoint are: operational requirements, operational requirement traceability, operational nodes, operational interactions, operational actors, operational tasks, operational activities, operational states, conceptual data, effectiveness constraints, and spatio-temporal information models; the views contained in the logical viewpoint are: system requirements, system requirement traceability, system composition, system interactions, system actors, system functions, system activities, system states, logical data, performance constraints, and system geometric models; and the views contained in the physical viewpoint are physical specifications, physical interfaces, physical data, and cyber-physical models; wherein in step 2, the development process of the UAS from the operational viewpoint comprises the following activities: (1) from a viewpoint of UAS operation, analyzing description of the operational concept provided by a user, transforming the operational concept into itemized operational requirements, and using an SysML requirement diagram for expression; (2) identifying relevant operational nodes from the operational requirements, and using an SysML block definition diagram for expression; (3) identifying main operational tasks from the operational requirements, and using an SysML use case diagram for expression; (4) defining operational activities for each operational task, as well as a control flow and an object flow between the operational activities, and assigning these activities to different swimlanes, using an SysML activity diagram for expression, wherein each swimlane is associated with the operational node; (5) defining conceptual data used in the system of systems model by analyzing the object flow in the operational activities, and using an SysML block definition diagram for expression; wherein the development process of the UAS from the operational viewpoint further comprises the following activities: based on activities (4) and (5), defining synchronous or asynchronous messages transferred between the operational nodes, and using an SysML sequence diagram for expression; (6) based on activities (4) and (5), transforming the control flow and object flow between different swimlanes into operation ports between the operational nodes, defining the conceptual data transferred in the operation ports, and using an SysML internal block diagram for expression; (7) analyzing a state that the operational node is capable of maintaining for a long time, associating the state with the operational activities assigned to the operational node in the swimlane, defining a state transition logic of the operational node, and using an SysML state machine diagram for expression; and (8) defining a measure of effectiveness (MOE) of the operational concept and a key performance parameter (KPP) of the operational node, establishing a constraint relationship between the MOE and the KPP, and using an SysML parametric diagram for expression; wherein in step 3, the development process of the UAS from the logical viewpoint comprises the following activities: (1) from a viewpoint of UAS designers, transforming the operational requirements assigned to operational nodes of the UAS into technical requirements of the UAS, and using an SysML requirement diagram for expression; (2) based on operational activities assigned to the operational nodes of the UAS, decomposing the operational activities into top-level functions of the UAS, and using an SysML use case diagram for expression; (3) based on the top-level functions of the UAS, decomposing and analyzing system functions with domain knowledge, assigning the functions to different swimlanes, and using an SysML activity diagram for expression; (4) defining internal components of the UAS by analyzing the swimlanes in the system activity diagram, and using an SysML block definition diagram for expression; (5) defining logical data of the system by analyzing a control flow and an object flow between the swimlanes in system activities, and using an SysML block definition diagram for expression; wherein the development process of the UAS from the logical viewpoint further comprises the following activities: based on activities (4) and (5), defining synchronous or asynchronous messages transferred between the operational nodes, and using an SysML sequence diagram for expression; (6) based on activities (4) and (5), transforming the control flow and the object flow between different swimlanes into logical ports between system elements, defining the logical data transferred in the logical ports, and using an SysML internal block diagram for expression; (7) analyzing a state that the system element is capable of maintaining for a long time, associating the state with the system activities assigned to the system element in the swimlane, defining a state transition logic of the system element, and using an SysML state machine diagram for expression; and (8) transforming a KPP assigned to the operational nodes of the UAS into a measure of performance (MOP) of the UAS, establishing a constraint relationship between the MOP of the UAS and an MOP of the system element, and using an SysML parametric diagram for expression; wherein in step 4, the development process of the UAS from the physical viewpoint comprises the following activities: (1) based on transformation standards of SysML and Modelica, transforming a hierarchical structure and a cross-linking relationship in a UAS model into a cyber-physical model of the UAS; (2) ensuring that the Modelica-based cyber-physical model of the UAS and an SysMLbased system description model have a same level, composition, and interface relationship, and developing a cyber-physical model of the components of the UAS with disciplinary knowledge; (3) based on an idea of componentized design, integrating a UAS component model containing multiple disciplines into a rapid prototype of the UAS from the bottom up according to the system level, composition, and interface relationship; (4) by using a non-causal Modelica solver, carrying out multi-disciplinary cosimulation to verify feasibility of MOPs of the system and a system element; (5) passing down design parameters verified by simulation as physical specifications, and using instance specification block definition diagrams in SysML for description; and (6) describing a physical interface and physical data involved in the physical specifications with the instance specification block definition diagrams in SysML; wherein in step 5, integration of cross-level spatio-temporal models, logical models, and mathematical models from the operational viewpoint, the logical viewpoint, and the physical viewpoint is carried out, and the three interfaces involved for integrated development comprises: (1) a spatio-temporal-logical interface: the spatio-temporal-logical interface mainly obtains event, signal, position, and distance data from the spatio-temporal model, and triggers execution of operational behaviors in the logical model, and the logical model drives simulation of the spatio-temporal model according to an operational logic and operational rules; (2) a logical-mathematical interface: the logical-mathematical interface mainly realizes transformation of structure, data, and interface between the logical model and the mathematical model, the logical model transfers a system architecture and metric constraints to the mathematical model, and the mathematical model feeds back solution results and physical parameters to the logical model; and (3) a mathematical-spatio-ternporal interface: the mathematical-spatio-temporal interface drives transformation of temporal and spatial information in the spatio-temporal model mainly based on real-time solution results of the mathematical model, thereby generating new events, signals, positions, and distances”. Independent claim 1, as drafted, is a process that, under the broadest reasonable interpretation, covers Mental Processes; and/or Certain Methods of Organizing Human Activity, since it recites commercial or legal interactions. If the claim limitations, under the broadest reasonable interpretation, covers mental processes and/or methods of organizing human activity but for the recitation of additional elements including generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Other than reciting the abstract idea, the independent claims recite additional elements including generic computer components such as “an electric device comprising a processor and a memory having program instructions stored, wherein the memory further stores a SysML logical model and a Modelica mathematical model” (see 112(a) rejections above), and nothing in the claims precludes the steps from being performed as a method of organizing human activity. Accordingly, the independent claims recite an abstract idea.
Step 2A, Prong 2 (Does the claim recite additional elements that integrate the judicial exception into a practical application?) – 2019 PEG pg. 54 (See MPEP 2106.04(d)-(c))
This judicial exception is not integrated into a practical application. In particular, independent claim 1 only recites the additional elements of “an electric device comprising a processor and a memory having program instructions stored, wherein the memory further stores a SysML logical model and a Modelica mathematical model” (see 112(a) rejections above)”. A plain reading of the Figures and associated descriptions in the specification fails to describe the additional elements. Therefore, generic processors may be used to execute the claimed steps. The additional elements are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using generic computer components (See MPEP 2106.05(f)) and limits the judicial exception to a particular environment (See MPEP 2106.05(h)). Mere instructions to apply an exception using a generic computer component and limiting the judicial exception to a particular environment doesn’t integrate the abstract idea into a practical application in Step 2A. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Hence, independent claim 1 is directed to an abstract idea..
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) – 2019 PEG pg. 56 (See MPEP 2106.05)
Independent claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the recited additional elements amount to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)) and limits the judicial exception to the particular environment of computers (See MPEP 2106.05(h)). The additional elements of the instant underlying process, when taken in combination, together do not offer substantially more than the sum of the function of the elements when each is taken alone. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept in Step 2B.
Subject Matter Overcoming 35 USC §102/§103
Claim 1 would be allowable if rewritten to overcome the rejections under 35 U.S.C. 101, 35 U.S.C. 112(a), and 35 U.S.C. 112(b), set forth in this Office Action.
Examiner’s statement of reasons for subject matter of independent claim 1 overcoming the prior art rejections under 35 USC §102/§103 was previously given in the nonfinal rejection dated 12/4/2025 and hence shall not be repeated here.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been fully considered by the Examiner. Applicant’s arguments with respect to the rejection of claim 1 under 35 USC 112(a) and 112(b) have been fully considered by the Examiner. However, the Examiner does not find the Applicant’s arguments persuasive, and therefore the rejections of claim 1 under 35 USC 112(a) and 112(b) are maintained. In regards to the rejections under 35 USC 112(a), Applicant argues that the individual steps are not entirely novel or detached from the foundation of the existing technologies but rather represent an integration and optimization of established mature technical frameworks. Applicant further states that DoDaF metal models and viewpoints constitute common knowledge in the field of system engineering. Applicant also explains that SysML is a general purpose architecture description and Modelica is a modeling language with both standard toolkits widely understood and utilized. Applicant further argues that the various steps are fundamental operations that those skilled in the art would know how to perform and although the claims employ functional language for generalization, the specification provides specific information to enable those skilled in the art to understand and implement the present application. In regards to the rejections under 35 USC 112(b), Applicant argues that the terms used are “standard technical terms” within the field of unmanned aerial vehicle system architecture design with clear and unambiguous meanings.
Examiner respectfully disagrees with Applicant’s arguments regarding the rejections pursuant to 35 U.S.C. 112(a) and 112(b). Applicant’s arguments are unpersuasive. As stated in the above final office action, there is not support for the claimed limitations of “an electric device comprising a processor and a memory having instructions stored thereon, wherein the memory further stores a SysML logical model and a Modelica mathematical model”, or any other additional elements for performing the claimed method. The specification does not provide adequate written description of how to perform any of the claimed steps of the claimed design method. To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019). Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. At best, the Specification vaguely and generically describes various steps for establishing an architecture development framework for an unmanned aerial vehicle system using functional language. The specification does not provdee specific information to enable those skilled in the art to understand and implement the present application. There is no description of what the steps/procedure actually entail or what technology is used implement the claimed steps of the method for designing the UAS. They are simply treated as labeled blocks on various diagrams. As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I.) In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function." The claims may include technical terms, but the specification does not at all describe the steps/procedure involved in the claimed method. The written description has not sufficiently met the requirements of 35 U.S.C. 112 with respect to the claimed limitations for the model-based architecture design method. In regards to the rejections pursuant to 35 U.S.C. 112(b), Applicant’s argument that the that the terms used are “standard technical terms” with clear and unambiguous meanings is also unpersuasive. The limitations are indefinite because it is unclear what makes up the claimed steps and it is also unclear what the limitations are referring to. As detailed further in the above final rejections, the claimed terms are not defined in the specification, it is unknown what technology is used to implement the claimed steps, and the specification does not specify any hardware or software for performing the method. Therefore the rejections pursuant to 35 U.S.C 112(a) and 35 U.S.C. 112(b) are maintained.
Applicant’s arguments with respect to the rejection of claim 1 under 35 USC 101 have been fully considered by the Examiner. However, the Examiner does not find the Applicant’s arguments persuasive, and therefore the rejection of claim 1 under 35 USC 101 is maintained. The Applicant argues that under Prong 1 of Step 2A of the 2019 PEG, the claims do not recite an abstract idea because the claims are directed to the field of unmanned aerial vehicle system (UAS) design and the operations are obviously performed by a computer that is not a general purpose computer but rather a “specific machine” that is integrated into a practical application. Applicant further argues that the additional technical elements provide concrete implementation parameters and amended claim 1 integrates the method into a practical application that solves a technical problems and achieves significant technical effect.
Examiner respectfully disagrees with Applicant’s argument that the claimed limitations do not recite any of the groupings of abstract ideas. Under Prong 1 of the 2019 PEG, the claims do fall under the abstract idea of Certain Method of Organizing Human Activity and Mental Processes. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, including marketing or sales activities, but for the recitation of additional elements including generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Under the broadest reasonable interpretation, the claims recite commercial or legal interactions, including marketing or sales activities and mental processes.
Examiner respectfully disagrees with Applicant’s argument that the claimed limitations are indicative of integration into a practical application under Prong 2 of Step 2A of the PEG. Although the Applicant may believe that it is obvious that the design method is performed by the a computer, as further indicated in the above 112(a) rejections, the Applicant’s specification, drawings, and original claim set fails to disclose “an electric device comprising a processor and a memory having instructions stored thereon, wherein the memory further stores a SysML logical model and a Modelica mathematical model” or any other structure for performing the claimed method. As further indicated in the above 112 rejections, At best, the Specification vaguely and generically describes establishing an architecture development framework for an unmanned aerial vehicle system. There is no description of what the steps/procedure actually entail or what technology is used implement the claimed steps of the method for designing the UAS. There is also no support for Applicant’s further argument that the claimed electric device comprising a processor is a “specific computer” and not a general purpose computer. Furthermore, even if there was support for “an electric device comprising a processor and a memory”, using a computer to: perform the claimed design method; is nothing more than executing instructions to apply the exception to a computer. This is interpreted by the Examiner as using a computer as a tool to perform an abstract idea (See MPEP 2106.05(f)). The additional claimed elements of “an electric device comprising a processor and a memory having program instructions stored, wherein the memory further stores a SysML logical model and a Modelica mathematical model” are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components (See MPEP 2106.05(f)). There is no improvement to the claimed computer elements, or to any other technology or technical field. The only improvements identified in the specification are generic speed and efficiency improvements inherent in applying the use of a computer to any task. Therefore, the claimed limitations do not meet the criteria or considerations as indicative of integration into a practical application. Therefore, the rejections of the claims pursuant to 35 USC 101 are maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul Schwarzenberg whose telephone number is (313) 446-6611. The examiner can normally be reached on Monday-Thursday (7:30-6:30).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Behncke, can be reached on (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PAUL S SCHWARZENBERG/Primary Examiner, Art Unit 3695 6/9/2025
Prosecution Insights