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 .
DETAILED ACTION
This action is in response to the preliminary amendment filed on 06/04/2024.
Claims 1-13 are amended by the applicants.
Claims 1-13 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a software module to edit the system description…
a second software module with a functionality for importing…
a receipt module to receive project-relevant information from other software modules…
an analysis module to perform calculations across all components and subcomponents…
an output module to transmit of system description data …in claim 10.
a third software module for editing and defining cross-system features… in claim 11.
a fourth software module for editing a description of interdependencies… in claim 12.
an output module to forward the system description data… in claim 13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
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-9 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding, claim 1, the limitation, “the features can be aggregated” is unclear as to whether the features are aggregated or not.
Regarding, claim 3, the limitation, “component descriptions is self-contained and can be considered independently” is unclear as to whether the component descriptions are considered independently or not.
Claims 2 and 4-9 are directly or indirectly depends from claim 1 and thus suffers the similar deficiency as claim 1.
Appropriate correction is required.
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-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1, this claim is within at least one of the four categories of patent eligible subject matter as it is directing to a method claim under Step 1.
1. (Currently Amended) A method for system description, the method comprising:
forming a standardized atomic base structure for description of individual components of a system, so all components are self-similar,
wherein the description includes a predefined set of features, aggregation rules, and interdependencies;
editing the system description by firstly dividing up hierarchically into individual components and subcomponents as far as an atomic base structure, and describing the individual components and subcomponents, wherein the descriptions of the individual components and subcomponents then form the hierarchical system description by definition and combination;
receiving project-relevant information from other software modules for sorting into the appropriate locations in the system description, wherein for processing a semantic description is given of how, when, and which data to be taken over from which software module or data repository;
analyzing the components using a recursive algorithm and deriving the characteristic values required for the system description;
wherein the definition of aggregation rules for individual components and subcomponents takes place such that the aggregation rules describe how the features can be aggregated across subcomponents;
calculating across all components and subcomponents of the system description and generating analysis results for the knowledge level of the system to be described; and
transmitting output of system description data in preset formats in accordance with specified rules.
Regarding claim 1, the limitations “forming a standardized atomic base structure for description of individual components of a system, so all components are self-similar, wherein the description includes a predefined set of features, aggregation rules, and interdependencies; editing the system description by firstly dividing up hierarchically into individual components and subcomponents as far as an atomic base structure, and describing the individual components and subcomponents, wherein the descriptions of the individual components and subcomponents then form the hierarchical system description by definition and combination,” and “analyzing the components using a recursive algorithm and deriving the characteristic values required for the system description wherein the definition of aggregation rules for individual components and subcomponents takes place such that the aggregation rules describe how the features can be aggregated across subcomponents; calculating across all components and subcomponents of the system description and generating analysis results for the knowledge level of the system to be described” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process.
For example, a person is capable of forming and editing the system description by component and subcomponents based on atomic structure with the aid of pen and paper to form the system description which utilized definition and rules. In same manner, a person is capable of generating results with the aid of pen and paper utilizing some algorithm/calculation for the system knowledge level description. Therefore, these limitations encompass a human mind carrying out the function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas because the recited calculation can be practically performed in the human mind under Prong 1.
Under Prong 2A, the additional elements “receiving project-relevant information from other software modules for sorting into the appropriate locations in the system description, wherein for processing a semantic description is given of how, when, and which data to be taken over from which software module or data repository,” and “transmitting output of system description data in preset formats in accordance with specified rules” merely recite insignificant extra solution activity such as gathering, updating, and transmitting data which does not integrate the judicial exception into a practical application. See MPEP § 2106.05(h).
Under Step 2B, the claims do 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 additional elements of “receiving project-relevant information from other software modules for sorting into the appropriate locations in the system description, wherein for processing a semantic description is given of how, when, and which data to be taken over from which software module or data repository,” and “transmitting output of system description data in preset formats in accordance with specified rules” the courts have identified functions such as data gathering/ updating/ including transmitting information over networks as well-understood, routine, conventional activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018)), thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
2. (Currently Amended) The method as claimed in claim 1, further comprising generating a standardized definition of interdependencies to other subcomponents.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
3. (Currently Amended) The computer implemented method as claimed in claim 1, wherein each of the individual component descriptions is self-contained and can be considered independently.
The limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
4. (Currently Amended) The method as claimed in claim 1, wherein dependencies to other components are defined at the respectively higher-level component level and are mirrored into the lower-level components.
The limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
5. (Currently Amended) The method as claimed in claim 1, wherein the recursive algorithm takes into account the follows a recursion rule that all paths are run through.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
6. (Currently Amended) The method as claimed in claim 1, wherein the recursive algorithm follows a recursion rule that the aggregation of the numerical values or other aggregatable individual features takes place in the components run through.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
7. (Currently Amended) The method as claimed in claim 1, wherein the recursive algorithm follows a recursion rule that dependencies are defined by the formation of references between tasks inside a component.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
8. (Currently Amended) The method as claimed in claim 1, wherein the recursive algorithm follows a recursion rule that individual features are only actively taken into account in connection with specified data constellations or for a specified calculation.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
Claim 10, this claim is within at least one of the four categories of patent eligible subject matter as it is directing to a system claim under Step 1.
10. (Currently Amended) A computer system comprising:
a memory module storing a system description;
a software module to edit the system description, wherein the system is firstly divided up hierarchically into individual components and subcomponents as far as an atomic base structure, and the individual components and subcomponents are described, wherein the descriptions of the individual components and subcomponents then form the hierarchical system description by definition and combination;
a second software module with a functionality for importing, copying, and organizing system description components;
a receipt module to receive project-relevant information from other software modules and for sorting into the appropriate locations in the system description, wherein for the automated processing a semantic description is given of how, when and which data is automatically to be taken over from which software module or data repository;
an analysis module to perform calculations across all components and subcomponents of the system description and generates analysis results for the knowledge level of the system to be described; and
an output module to transmit of system description data in preset formats in accordance with specified rules.
Regarding claim 10, the limitations “a software module to edit the system description, wherein the system is firstly divided up hierarchically into individual components and subcomponents as far as an atomic base structure, and the individual components and subcomponents are described, wherein the descriptions of the individual components and subcomponents then form the hierarchical system description by definition and combination,” and “an analysis module to perform calculations across all components and subcomponents of the system description and generates analysis results for the knowledge level of the system to be described” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. For example, a person is capable of editing the system description by component and subcomponents based on atomic structure with the aid of pen and paper to form the system description which utilized definition and rules. In same manner, a person is capable of generating results with the aid of pen and paper utilizing some algorithm/calculation for the system knowledge level description. Therefore, these limitations encompass a human mind carrying out the function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas because the recited calculation can be practically performed in the human mind under Prong 1.
Under Prong 2A, the additional elements “computer system,” “a memory module storing a system description,” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, See MPEP 2106.05(f). For the additional elements “a second software module with a functionality for importing, copying, and organizing system description components; a receipt module to receive project-relevant information from other software modules and for sorting into the appropriate locations in the system description, wherein for the automated processing a semantic description is given of how, when and which data is automatically to be taken over from which software module or data repository,” and “an output module to transmit of system description data in preset formats in accordance with specified rules” merely recite insignificant extra solution activity such as gathering, updating and output/transmitting data which does not integrate the judicial exception into a practical application. See MPEP § 2106.05(h).
Under Step 2B, the claims do 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 additional elements of “computer system,” “a memory module storing a system description,” amount to no more than mere instructions, or generic computer and/or computer components to carry out the exception. See MPEP 2105.06(f). For the claims do 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 additional elements of “receiving project-relevant information from other software modules for sorting into the appropriate locations in the system description, wherein for processing a semantic description is given of how, when, and which data to be taken over from which software module or data repository,” and “transmitting output of system description data in preset formats in accordance with specified rules” the courts have identified functions such as data gathering/ updating including transmitting information over networks as well-understood, routine, conventional activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368, 125 USPQ2d 1649, 1654 (Fed. Cir. 2018)), thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 USC 101.
9. (Currently Amended) The method as claimed in claim 8, wherein a specified calculation is a specified task which arises only under specified conditions.
The limitations for this claim further recite an additional mental process under Step 2A, Prong 1.
11. (Currently Amended) The computer system as claimed in claim 10, having a third software module for editing and defining cross-system features.
The limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
12. (Currently Amended) The computer system as claimed in claim 10, having a fourth software module for editing a description of interdependencies between individual subcomponents, in particular on the basis of a predefined semantic vocabulary.
The limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
13. (Currently Amended) The computer system as claimed in claim 10, having an output module to forward the system description data to other systems in accordance with specified rules.
The limitations for this claim further recite an additional insignificant extra solution activity under step 2A, Prong 2.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Related cited arts:
Lédeczi, Ákos, et al. "Composing domain-specific design environments." Computer 34.11 (2001): pp.44-51.
Karsai, Gabor, et al. "Model-integrated development of embedded software." Proceedings of the IEEE 91.1 (2003): pp. 145-164.
Engels, Gregor, et al. "Building integrated software development environments. Part I: tool specification." ACM Transactions on Software Engineering and Methodology (TOSEM) 1.2 (1992): pp. 135-167.
US8473910 - A method and system include capturing one or more process flow definitions that define, at least in part, a software application. One or more user interface definitions that define, at least in part, an interface to the software application are captured. One or more data definitions that define, at least in part, data used within the software application are captured. One or more rules for validating at least part of the software application are captured. A design definition is captured as a specification wherein the design definition includes: the one or more process flow definitions, the one or more user interface definitions, the one or more data definitions, and the one or more rules.
US20200042291 - A software system generating system comprises a specification generating module and a software system generating module wherein the software system generating module outputs a structured specification according to information being provided by user's demand; the software system generating module includes a plurality of predefined elements which each element is a programmable unit; the structured specification defines characteristics of the element to generate forms which the characteristic is a combination relationship of the plurality of predefined elements; after inputting the structured specification into the software system generating module and processing through a coding process, the software system generating module generates a system menu and its relevant links based on the analyzed system architecture to form a complete processing procedure; and the software system generating module complies and interprets the system program code combination to generate the result system.
US8386999 - A method and system of analyzing a software design includes receiving one or more specifications containing one or more design elements. One or more design elements not included in the one or more specifications are identified. One or more design elements not included in the one or more specifications are generated. The one or more generated design elements are added to the one or more specifications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Satish Rampuria whose telephone number is 571-272-3732. The examiner can normally be reached on Monday-Friday from 8:30 AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/Satish Rampuria/Primary Examiner, Art Unit 2193
*****
Prosecution Insights