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 .
All objections/rejections not mentioned in this Office Action have been withdrawn by the Examiner.
Response to Amendments
Applicant’s amendment filed on 08 August 2025 has been entered.
In view of the amendment to the claim(s), the amendment of claim(s) 1, 8, 11, and 17 and the cancellation of claim(s) 6, 15, 20, and 21 have been acknowledged and entered.
In view of the amendment to claim(s) 1, 8, 11, and 17 and the cancellation of claim(s) 6, 15, 20, and 21, the rejection of claim(s) 8 and 11-19 under 35 U.S.C. §112 is withdrawn.
In view of the amendment to claim(s) 1, 8, 11, and 17 and the cancellation of claim(s) 6, 15, 20, and 21, the rejection of claims 6, 15, 20, and 21 under 35 U.S.C. §101 is withdrawn. The rejection(s) of claim(s) 1-5, 7-14, and 16-19 under 35 U.S.C. §101 is/are maintained as modified in response to amendment, for the reasons provided in the action below.
In view of the amendment to claim(s) 1, 8, 11, and 17 and the cancellation of claim(s) 6, 15, 20, and 21, the rejection of claims 6, 15, 20, and 21 under 35 U.S.C. §102 and 103 is withdrawn. The rejection(s) of claim(s) 1-5, 7-14, and 16-19 under 35 U.S.C. §102 and 103 is/are maintained as modified in response to amendment, for the reasons provided in the action below.
Response to Arguments
Applicant’s arguments regarding the statutory subject matter rejections under 35 U.S.C. §101, see pages 11-13 of the Response to Non-Final Office Action dated 09 May 2025, which was received on 08 August 2025 (hereinafter Response and Office Action, respectively), have been fully considered.
Claim 6, 15, 20, and 21 are canceled in the Response. Therefore, the rejections of said claims are withdrawn.
Regarding the rejection of claims 1-5, 7-14, and 16-19 under 35 U.S.C. 101, applicant appears to be arguing that claims 1 and 11, as amended, incorporate a requirements knowledge map and a requirements knowledge module, respectively, which applicant asserts integrates any asserted judicial exception into the practical application under Step 2A, Prong 2, of the Alice/Mayo test. (Response pg. 11-12, See MPEP 2106.04(II)(A)(2)). These arguments are not persuasive.
Applicant relies largely on the argument that claims 1 and 11 recite a requirements knowledge map which is asserted to provide “a specific technical solution, rather than merely reciting an abstract idea”. However, the requirements knowledge map, as defined in applicant’s specification is the abstract idea. The specification defines the role of the requirements knowledge map as “to define the relationship between two proper nouns” where the relationship between the two is “defined by the user”. (Instant Application, [0063]). As such, the described “requirements knowledge” of the requirements knowledge map/module is human (e.g., user) knowledge, which is merely applied to a computing environment in a generic fashion. The court has consistently held that “[s]teps that do nothing more than spell out what it means to ‘apply it on a computer’ cannot confer patent-eligibility.” Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1371-72 (Fed.Cir. 2015)(citing Alice, 134 S.Ct. at 2359 (warning against a § 101 analysis that turns on the draftsman's art (citing Parker v. Flook, 437 U.S. 584, 593, 98 S.Ct. 2522, 57 L.Ed.2d 451 (1978))).
Though asserts by that applicant that the “technical means are not simple manual reviews or human-to-human interactions, but are specific and automated technical solutions,” and that “the requirement knowledge map… goes beyond the scope of manual management that could be replicated by a human alone,” applicant’s claims recite nothing more than said “manual management” which appears to be based on and perform the same in a computer context. The “technical means” relied on in applicant’s response if the requirements knowledge map/module.
Applicant further argues that “the content recited in claim 1, as amended, of this application is technical, and the steps recited in claim 1, as amended, together constitute a particular solution and a detailed and particular way to achieve the desired technical improvement” which “is not merely directed to the abstract ideas of organizing human activity and a mental process” and that claim 1 has, as a result, “integrated any allegedly abstract concepts into a practical application and thus complies with the requirements of § 101”. However, this argument is not persuasive.
Applicant’s improvement merely uses the technology as a platform and is not tantamount to an improvement to existing technology. The court has indicated that an abstract idea which constitutes an improvement to an existing technology can overcome a rejection under 35 USC 101. (The court agreed with Enfish, which argued that its claimed self-referential table for a computer database was an improvement in an existing technology and thus not directed to an abstract idea. Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336-37, 118 USPQ2d 1684, 1689-90 (Fed. Cir. 2016).) However, the question turns on whether the improvement is directed to the existing technology itself, or if the improvement merely uses said existing technology as a platform for delivering the abstract idea.
The instant application is directed to systems and methods which perform requirements processing for requirements engineers. (Instant Application, [0004]). The recited steps of the claim 11 are directed to performing requirements processing in a computing environment. Claim 1 does not recite or require a computing device at all (admittedly, such a recitation would not change the analysis). Each of the steps, though likely performed in the context of a computing system, do not affect or change the computing system itself (unlike, Enfish, which claimed a logical model for a computer database). As such, this is an improvement to requirements processing as implemented on a computing device, not an improvement to the computing device itself. Therefore, the rejection under 101 is maintained over the above arguments.
Applicant’s arguments regarding the prior art rejections under 35 U.S.C. §102/103, see pages 13-19 of the Response, have been fully considered.
With respect to the rejection(s) of claim(s) 1, and mutatis mutandis claim 11, under 35 U.S.C. 102(a)(2) as being anticipated by Parrish (U.S. Pat. App. Pub. No. 2022/0382977, hereinafter Parrish), applicant asserts that Parrish fails to teach or suggest all limitations of claim 1 as amended. Applicant’s arguments are not persuasive for the reasons discussed below.
In response to applicant's arguments that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “dynamically update its predetermined usage rules,” “dynamic reasoning ability based on semantic relationships,” “dynamic verification of labels and document structures” “dynamic semantic expansion of proper nouns through the requirement knowledge map” “automatic completion of requirement documents”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Further, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Applicant provides a general argument that “Claim 1, as amended, includes at least the following distinguishing technical features: * introducing a requirements knowledge map to semantically expand a proper noun in the requirements, wherein the step of introducing a requirements knowledge map comprises: semantically supplementing two proper nouns according to a predetermined relationship between the two proper nouns, so as to determine the requirement conformity between the several upper-level requirements and the corresponding lower-level requirements thereof,* checking a requirement traceability relationship; checking a requirement traceability label existing in the requirements document, so as to check the consistency between the requirement traceability label and an actual structure of the requirements document; and * automatically supplementing the requirements document.” (Response, pg. 14). Applicant’s “distinguishing technical features” are understood to be an argument that Parrish fails to teach or suggest these limitations. However, applicant fails to associate the specific limitations of amended claim 1 to any specific deficiency in the presented mapping to cited portions of Parrish.
Respectfully, applicant is citing the vast majority of claim 1, followed by a generic assertion that claim 1 is patentable over the cited reference, while failing to provide further explanation directed to the individual limitations and what specific portions of the mapping is believed to be deficient with respect to a specific individual limitation. For example, applicant’s response regarding claim 1, which starts on pg. 13, begins with the asserted “distinguishing technical features” of the claims, followed by asserted “technical problems solved” by the invention, and then the applicant asserts that “domain model disclosed in Parrish is different from the requirement knowledge map recited in claim 1 of the present application, as amended,” which is followed by the entirety of paragraph [0077], and applicant’s interpretation of Figure 7 and paragraph [0077] of Parrish. (Response, pgs. 14-15). Paragraph [0077] of Parrish corresponds to the rejection of claim 6, and applicant provides an interpretation of the cited portions of the Parrish reference. Aside from the general assertion that “domain model disclosed in Parrish is different from the requirement knowledge map”, a point which is not conceded here, there is no clear connection between the cited “technical features” and any specific limitation from claim 6 as previously presented, or to claim 1 as currently amended.
This interpretation is followed by numerous statements of deficiency, but said deficiencies do not have a clear correspondence to limitations recited in the claims. For example, assuming, arguendo, that the assertion that “The domain model in Parrish is a relatively static attribute rule base, used to improve the ability of NLP algorithms to understand specific texts, and its core function is to provide static dictionary support for NLP algorithms, such as mapping abbreviations to full names” is true, it remains unclear how said statement is related to any specific asserted limitation of claim 1. Instead, applicant asserts that the above argument supports the conclusion that “[t]he domain model cannot achieve the technical effect of semantic supplementation, and the domain model in Parrish cannot dynamically update its predetermined usage rules.” However, though semantic supplementation is part of the claims, the asserted limitation “achieve the technical effect of semantic supplementation” is not part of the claims and the basis upon which the applicant is distinguishing this phrase is unclear.
Respectfully, the phrase “semantic supplementation” is not a term of art in the relevant art area (it is noted that “semantic supplementation” does occur in the medical field, with relation to dysarthria). In light of lack of usage in the art, applicant’s specification fails to provide clear lexicographical meaning for the term such that the examiner can consider the asserted deficiency in the absence of a specific claim limitation. To address the generic argument as best as possible, applicant is provided an example of semantically supplementing two proper nouns (e.g., “Dassault Rafale” and the associated entity in the domain model) based on the “unique meaning within the user's domain of interest” where there would otherwise be no meaning. (Parrish, [0077]). Respectfully, this is understood as a semantic supplementation which is provided by the domain model. However, as the applicant’s concern regarding this phrase in light of the mapping is unclear, said arguments cannot be further addressed.
Further, the assertion that Parrish cannot “dynamically update its predetermined usage rules” fails to provide a clear basis for reconsideration for two reasons. First and foremost, the asserted limitation is not recited in the claims as amended. It is further noted that the word “dynamic”, and the related but distinct phrase “real-time”, both lack clear support in either of the claims or the specification. Second, the asserted limitation has an apparent internal conflict. Specifically, it is unclear how a predetermined usage rule can be both “predetermined” and “dynamically update[d]”. Even if we assume that the word “dynamic” has support, the amended claim language recites “semantically supplementing two proper nouns according to a predetermined relationship.” If the relationship is predetermined, in what way is the same relationship being asserted as “dynamic”? A “predetermined relationship” considered in light of “predetermined usage rules”, is not understood as dynamic. Nevertheless, even if said dynamic aspects are explained, such language is not part of the claims as presented or amended.
As a result, though applicant does at least implicitly argue that a majority of the cited limitations of amended claim 1 is not taught by Parrish (see Response, pg. 14), these arguments lack any directed or supporting explanation as to how the mapping of Parrish provided in the Office Action fails to teach the cited limitation. Therefore, the arguments provided amount to a general assertion of patentability and said arguments are improper. The rejection is maintained in light of the provided arguments.
Claim 6, 15, 20, and 21 are canceled in the Response. Therefore, the rejections of said claims are withdrawn.
Applicant further argues that the rejection(s) of dependent claims 2-5, 7-10, 12-14, and 16-19 should be withdrawn for at least the same reasons as independent claims 2-5, 7-10, 12-14, and 16-19. Applicant’s arguments in light of the amended claims are not persuasive for the reasons described in response to the arguments above. As such, the rejections of claims 2-5, 7-10, 12-14, and 16-19 under 35 U.S.C. §102 and 35 U.S.C. §103 are maintained as modified for clarity and in response to the amendments.
The Applicant has not provided any further statement and therefore, the Examiner directs the Applicant to the below rationale.
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(s) 1-5, 7-14, and 16-19 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more. The independent claim(s) 1, and mutatis mutandis claim(s) 11, recite “obtaining a requirements document that needs to be parsed, and viewing a requirement in the requirements document; performing requirement conformity parsing on several upper-level requirements and corresponding lower-level requirements thereof in the requirements document; introducing a requirements knowledge map to semantically expand a proper noun in the requirements, wherein the step of introducing a requirements knowledge map comprises: semantically supplementing two proper nouns according to a predetermined relationship between the two proper nouns, so as to determine the requirement conformity between the several upper- level requirements and the corresponding lower-level requirements thereof; checking a requirement traceability relationship; checking a requirement traceability label existing in the requirements document, so as to check the consistency between the requirement traceability label and an actual structure of the requirements document; and automatically supplementing the requirements document”
Regarding claim(s) 1 and 11, the limitations of “obtaining…”, “performing…”, “introducing…”, “checking…”, and “automatically supplementing…” as drafted cover managing personal behavior or relationships or interactions between people, which is a method of organizing human activity. More specifically, a first person receives and reviews a requirements document from a second person, including one or more upper-level and lower level requirements. The first person then itemizes and reviews the individual requirements as listed in the document, specifically comparing upper-level requirements to the related lower level requirements based on various requirements document standards as known in the art (e.g., International Council on Systems Engineering (INCOSE) standards for well-written requirements, etc.), the first person then semantically expands on a proper noun (e.g., in an example requirement that includes a “Customer Relationship Management (CRM) system”, the person can generate a knowledge map with the proper noun being the central node, to semantically expand this to determine the specific system to be modified, key features, integration points, etc.). The first person can further determine relationships between the requirements (e.g., using a requirements knowledge map) such that the first person can identify potential issues or gaps between the upper level and lower level requirements. The first person then presents the above described analyses to the second person. Therefore, the claims are directed to human activity, and, thus, directed to an abstract idea.
The judicial exception is not integrated into a practical application. In particular, claim(s) 1 and 11 recite additional elements of a “viewing module” and “processing module,” as per the independent claims. However, the “viewing module” and “processing module,” is/are not meaningfully integrated into the practical application of the abstract ideas recited in claim(s) 1 and 11. For example, at paragraph(s) [0043] and [0072] of the as filed specification, there is description of a “viewing module”; and at paragraph(s) [0013], [0027], [0058], [0061], [0073], and [0077] there is a description of an “processing module”. However, these are general-purpose computer components with no provisions for the practical application of the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional element of using the “viewing module” and “processing module,” is noted as general computer components. Respectively, the additional element of using the “viewing module” and “processing module,” is noted as general purpose computer components as part of a generic computing device. Mere instructions to apply an exception using a generic computing device or general purpose computer component cannot provide an inventive concept. As the claims do not amount to significantly more than the judicial exception, claims 1 and 11 are not patent eligible.
With respect to claim(s) 2 and 12, the claims relate to the use of natural language processing as part of a requirement conformity evaluation system. As performed by a person, these steps appear to refer to the mental process of understanding the words written in the requirements document and extracting the semantic meaning of the words. No additional limitation is present.
With respect to claim(s) 3 and 13, the claims relate to specifically enumerating the consistency check between the upper and lower level requirements in the requirements document. As performed by a person, these steps appear to refer to the mental/administrative/clerical process of reviewing the requirements document for logical consistency and completeness between the specific requirements. No additional limitation is present.
With respect to claim(s) 4, the claims relate to the use of a Stanza language processing module for the natural language processing module. As performed by a person, these steps appear to refer to the mental process of understanding the semantic meaning of text, as modified through the use of a generic computer component. No additional limitation is present.
With respect to claim(s) 5 and 14, the claims relate to specifics of the core content of a requirement in a requirements document. This further limitation appears to refer to recite the elements of a sentence as used to describe a requirement. No additional limitation is present.
With respect to claim(s) 7 and 16, the claims relate to comparing traceability labels between upper and lower level requirements. As performed by a person, these steps appear to refer to the mental process of making sure that labels for elements in a document are properly organized such that the same elements described in different portions of the document are in logical agreement. No additional limitation is present.
With respect to claim(s) 8 and 17, the claims relate to generating additional information for the requirements document using machine learning. As performed by a person, these steps appear to refer to the mental process of determining important elements in a document and expanding the description based on information which is logically missing or incomplete. No additional limitation is present.
With respect to claim(s) 9 and 18, the claims relate to specific machine learning models being used in the described systems. As performed by a person, these steps appear to refer to the previously described mental process as performed by a specific generic computing device. No additional limitation is present.
With respect to claim(s) 10 and 19, the claims relate to a specific format for the viewed dependency relationship. As performed by a person, these steps appear to refer to the mental and clerical process of providing results of the analysis in a specified format. No additional limitation is present.
These claims further do not remedy the judicial exception being integrated into a practical application and further fail to include additional elements that are sufficient to amount to significantly more than the judicial exception. As such, for the same reasons as described above with reference to independent claim(s) 1 and 11, dependent claim(s) 2-10 and 12-19 are not patent eligible.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3, 5, 7-14, and 16-19 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Parrish (U.S. Pat. App. Pub. No. 2022/0382977, hereinafter Parrish).
Regarding claim 1, Parrish discloses A requirement conformity parsing method, comprising (systems and methods for “for automated analysis of engineering requirements”; Parrish, ¶ [0033]): obtaining a requirements document that needs to be parsed (The system receives “a first list of engineering documents uploaded by a user, wherein the first list comprises one or more engineering requirement documents {obtaining a requirement document}” where uploaded by a user indicates that the uploaded documents need to be parsed.; Parrish, ¶ [0033]), and viewing a requirement in the requirements document (“processing the one or more selected engineering requirement documents from the first list using one or more artificial intelligence (AI)-based natural language processing algorithms” where, as described with reference to an example, the system accurately traces “document requirements for complex systems engineering projects while conforming to professionally-recognized standards for engineering requirements documents {viewing a requirement in the requirements document}”; Parrish, ¶ [0033], [0130]); performing requirement conformity parsing on several upper-level requirements and corresponding lower-level requirements thereof in the requirements document (In the example, “the aforementioned custom corpuses of words and common/regular expressions have been incorporated into custom Python routines” as part of the system “which are iteratively run against all uploaded requirement descriptions. A color gradient is then used to indicate requirements that fail to conform to quantity standards and the number of quality rules that a given requirement description breaks.”; Parrish, ¶ [0130], [0132]); introducing a requirements knowledge map to semantically expand a proper noun in the requirements (The system can “define relationships between semantically-similar acronyms, words, and/or phrases {semantically expand a proper noun in the requirements}” using the “requirements analysis using artificial intelligence for mapping (RAAM) tool”; Parrish, ¶ [0034], [0022]), wherein the step of introducing a requirements knowledge map comprises: semantically supplementing two proper nouns (Discloses the mappings can include the comparison of “Domain-specific terminology” to determine requirements conformity using the “domain models” which “define common English definitions and replacements of domain-specific acronyms, out-of-vocabulary terminology, and mappings between terminology” and provides an example domain specific term “Dassault Rafale” which the system maps to the associated entity found in the domain model, where “Dassault Rafale” is a proper noun and the associated entity in the domain model (which corresponds to “Dassault Rafale” based on the user input) is also a proper noun; Parrish, ¶ [0077]) according to a predetermined relationship between the two proper nouns (The domain specific terms “Dassault Rafale”, which is the name of a model of fighter aircraft, and the associated acronym, have a predetermined relationship which is mapped in the domain model; Parrish, ¶ [0077]), so as to determine the requirement conformity between the several upper-level requirements and the corresponding lower-level requirements thereof (“Mappings” are “user-defined associations between words or phrases which may indicate that two documents are related {the several upper-level requirements and the corresponding lower level requirements}” and users “utilize these domain models when using the software’s engineering documents-analyzing capabilities {so as to determine the requirement conformity between...}.”; Parrish, ¶ [0077]); checking a requirement traceability relationship (The system includes a “linking table” with “(i) the capability to compare two sets of requirements and determine, for each requirement in a first set of requirements, a list of requirements in a second set of requirements that are the most similar semantically {checking a requirements traceability relationship}”; Parrish, ¶ [0037]); checking a requirement traceability label existing in the requirements document, so as to check the consistency between the requirement traceability label and an actual structure of the requirements document (The system can “define relationships between semantically-similar acronyms, words, and/or phrases {semantically expand a proper noun in the requirements}” where “the results may be exported at step 544 as a merged requirements file 546 {existing in the requirements document}...in a standard linking matrix format 540” which includes “the requirement’s universally unique identifier (UUID) {a requirements traceability label} and requirements text”; Parrish, ¶ [0034], [0075], [0128]); and automatically supplementing the requirements document (The system further detects “faulty universal unique identification numbers (UUIDs)”, “incorrectly formatted hierarchy values (ex. 1-2 instead of 1.)”, and “faulty description columns”. As well, the system can iteratively link a “parent to its children and vice versa for requirements within a hierarchical document,” where “duplicate UUIDs or faulty hierarchy values are flagged for the user and a failed traceability alert is issued”; Parrish, ¶ [0118]).
Regarding claim 2, Parrish discloses wherein the requirement conformity parsing comprises: establishing a conformity evaluation system for checking the consistency between the several upper-level requirements and the corresponding lower-level requirements thereof (“The RAAM Traceability tool provides the user with the functionality to accurately trace and document requirements for complex systems engineering projects {establishing a conformity evaluation system}” to “understand how high-level requirements... are transformed into lower-level requirements” by “identifying and ensuring that relationships between different layers of information (e.g., engineering artifacts) are satisfied”; Parrish, ¶ [0116]-[0117]); using a natural language processing module to construct a requirement statement model from the several upper-level requirements and the several lower-level requirements, respectively (“RAAM Traceability tool include extracting requirements from Excel spreadsheets into a digitized serialized format, automated matching of similar-meaning requirements based on NLP-based document similarity analysis, generation of linking tables or merged files, and creation, population, and usage of domain models” to document “relationships between many kinds of development artifacts, e.g., system or software requirements, specification statements, designs, models and prototypes, testing protocols and test data, developed system or software components, etc.”; Parrish, ¶ [0116]-[0117]); extracting a core content of the requirement by the requirement statement model (The system includes “automated matching of similar-meaning requirements based on NLP-based document similarity analysis” where determining a similar meaning is the extraction of a core concept; Parrish, ¶ [0017]); and performing syntax parsing, semantic parsing and classifier parsing respectively on the core content of the requirement through the conformity evaluation system (Further discloses “requirement extraction and serialization capability includes, for example, detection of faulty universal unique identification numbers (UUIDs) {classifier parsing}, detection of incorrectly formatted hierarchy values (ex. 1-2 instead of 1.) {syntax parsing}, and detection of faulty description columns {semantic parsing}” and further “iteratively links parent to its children and vice versa for requirements within a hierarchical document.”; Parrish, ¶ [0118]), and giving a final evaluation result (“The tool also enables the optional creation of a summarized view of the results of the requirements quality analysis. “; Parrish, ¶ [0134]).
Regarding claim 3, Parrish discloses wherein the consistency between the several upper-level requirements and the corresponding lower-level requirements thereof is the consistency between entities and behaviors of the entities described by the several upper-level requirements and the corresponding lower-level requirements (“The RAAM Traceability tool provides the user with the functionality to accurately trace and document requirements for complex systems engineering projects {establishing a conformity evaluation system}” to “understand how high-level requirements... are transformed into lower-level requirements” by “identifying and ensuring that relationships between different layers of information (e.g., engineering artifacts) are satisfied” where the system judges consistency at both the entities which define exemplary artifacts (e.g., “designs, models and prototypes,” and “developed system or software components”) and the behaviors of those entities (e.g., “system or software requirements” in light of “testing protocols and test data”) to determine consistency.; Parrish, ¶ [0116]-[0117]).
Regarding claim 5, Parrish discloses, wherein the core content of the requirement comprises a subject (As shown in the example of FIG. 8, “the architecture shall support real-time situational awareness across all modules”, the core content of a requirement comprises the subject (e.g., “The architecture”); Parrish, ¶ [0078], FIG. 8), an object (Relying on the same example, the core content of a requirement comprises the object (e.g., “real-time situational awareness”).; Parrish, ¶ [0078], FIG. 8), a syntactical relationship formed by subject-verb-object (Relying on the same example, the core content of a requirement comprises the syntactical relationship formed by subject-verb-object (e.g., “shall support” being the verb which establishes the action or state which the subject must adhere to with respect to the object).; Parrish, ¶ [0078], FIG. 8) and a quantity relationship formed by subject-keyword-object of the requirement statement (Relying on the same example, the core content of a requirement comprises a quantity relationship formed by the subject-keyword-object of the requirement statement (e.g., “across all modules/components” where the architecture is the implied subject, across acts as a key word indicating scope or distribution, and “all modules/components” is the object specifying the extent of the “Real-time situational awareness”); Parrish, ¶ [0078], FIG. 8).
Regarding claim 7, Parrish discloses wherein requirement traceability labels of the several upper-level requirements and the corresponding lower-level requirements thereof are compared with the structure of the requirements document (“Examples of the one or more post-processing steps that may be performed following document text matching include, but are not limited to, (i) evaluation of the similarity between sets of vectorized documents” and “iteratively sets links to parent and children for requirements within a hierarchical document, and provides detection of duplicate UUIDs or hierarchy values”; Parrish, ¶ [0070], [0130]), and a checking result of the requirement traceability relationship is configured to assist the requirement conformity parsing of the several upper-level requirements and the corresponding lower-level requirements thereof (“the disclosed methods and systems perform post-processing of results derived from the one or more machine learning (ML)-based natural language processing (NLP) models... such that it can be interpreted and used by the next stage in the system” which can “involve consolidating the two results into a single output” that describes the similarity between the requirements and “requirement quality analysis algorithms include pattern matching using common/regular expressions to detect certain word formations within requirement descriptions that indicate the presence of a violation of an INCOSE or IEEE rule.; Parrish, ¶ [0070]).
Regarding claim 8, Parrish discloses wherein the step of automatically supplementing the requirements document comprises: using a historical requirements document to train a machine learning model (“the disclosed methods and systems may utilize one or more supervised machine learning algorithms, i.e., algorithms that rely on the use of a set of labeled training data to infer the relationship between input text and a classification of the text according to a user-specified set of text categories. In some instances, the labeled training data set comprises a set of paired training examples, e.g., where each example comprises input text and the resultant classification of the text.”; Parrish, ¶ [0088]), and to determine whether the historical requirements document needs to be added to a semantic consistency determination according to a feedback (As stated previously, the system may be trained using “a set of labeled training data to infer the relationship between input text and a classification of the text according to a user-specified set of text categories” where user-specified is according to a feedback.; Parrish, ¶ [0088]); and automatically generating, after writing some requirements, a required requirements document according to the historical requirements document and the semantic parsing (“The disclosed methods and systems provide the capability to upload requirements documents from a plurality of legacy programs and process them to quickly and efficiently generate a single, comprehensive, and updated requirements document that complies with INCOSE and/or IEEE requirements standards.”; Parrish, ¶ [0115]).
Regarding claim 9, Parrish discloses wherein the machine learning model is selected from any one of transformer, n-gram, and GPT-2. (“Document text is input on a word-by-word basis (e.g., Word 1 (402), Word 2 (404), Word 3 (406), Word 4 (408), and Word 5 (410)) via input layer 412 and processed by a transformer encoder 414 before being output”; Parrish, ¶ [0063]).
Regarding claim 10, Parrish discloses wherein the viewing a requirement is a view of dependency relationship between the requirements (As depicted in the example of FIG. 8, “a listing of specific requirements derived from a requirements document may be displayed, e.g., in panel 808 at the left side of the GUI,” is a view of a dependency relationship between the requirements.; Parrish, ¶ [0078], FIG. 8), and after obtaining the requirements document, a requirement dependency tree is constructed (The panel 808 is constructed based on one or more uploaded requirements documents.; Parrish, ¶ [0076], [0078], FIGS. 6 and 8), and a component of the requirement is viewed through the requirement dependency tree displayed through a front end, so as to correct a non-standard syntactical writing (The displayed GUI is viewed through a front end where the requirements may be validated and updated.; Parrish, ¶ [0076], [0078], FIGS. 6 and 8).
Regarding claim 11, Parrish discloses A requirement conformity parsing system, comprising (systems and methods for “for automated analysis of engineering requirements”, where said systems and methods can be implemented as “a computer program... that resides in memory and facilitates interactions between the hardware and software components of the computing platform”; Parrish, ¶ [0033]-[0034], [0052]): a viewing module, configured to visualize a requirement in a requirements document (“processing the one or more selected engineering requirement documents from the first list using one or more artificial intelligence (AI)-based natural language processing algorithms” where, as described with reference to an example, the system accurately traces “document requirements for complex systems engineering projects while conforming to professionally-recognized standards for engineering requirements documents {viewing a requirement in the requirements document}”; Parrish, ¶ [0033], [0130]); a processing module, connected to the viewing module, wherein the processing module is configured to construct a requirement statement model from several upper-level requirements and several lower-level requirements (In the example, “the aforementioned custom corpuses of words and common/regular expressions have been incorporated into custom Python routines” as part of the system “which are iteratively run against all uploaded requirement descriptions. A color gradient is then used to indicate requirements that fail to conform to quantity standards and the number of quality rules that a given requirement description breaks.”; Parrish, ¶ [0130], [0132]); a knowledge map module, connected to the processing module, wherein the knowledge map module semantically expands a proper noun in the requirement (The system can “define relationships between semantically-similar acronyms, words, and/or phrases {semantically expand a proper noun in the requirements}” using the “requirements analysis using artificial intelligence for mapping (RAAM) tool”; Parrish, ¶ [0034], [0022]), wherein the knowledge map module semantically supplements two proper nouns (Discloses the mappings can include the comparison of “Domain-specific terminology” to determine requirements conformity using the “domain models” which “define common English definitions and replacements of domain-specific acronyms, out-of-vocabulary terminology, and mappings between terminology” and provides an example domain specific term “Dassault Rafale” which the system maps to the associated entity found in the domain model, where “Dassault Rafale” is a proper noun and the associated entity in the domain model (which corresponds to “Dassault Rafale” based on the user input) is also a proper noun; Parrish, ¶ [0077]) according to a predetermined relationship between the two proper nouns (The domain specific terms “Dassault Rafale”, which is the name of a model of fighter aircraft, and the associated acronym, have a predetermined relationship which is mapped in the domain model; Parrish, ¶ [0077]), for determining the requirement conformity between the several upper-level requirements and the corresponding lower-level requirements thereof (“Mappings” are “user-defined associations between words or phrases which may indicate that two documents are related {the several upper-level requirements and the corresponding lower level requirements}” and users “utilize these domain models when using the software’s engineering documents-analyzing capabilities {so as to determine the requirement conformity between...}.”; Parrish, ¶ [0077]); a checking module, connected to the knowledge map module, wherein the checking module is configured to check a requirement traceability label existing in the requirements document (The system includes “(i) the capability to compare two sets of requirements and determine, for each requirement in a first set of requirements, a list of requirements in a second set of requirements that are the most similar semantically {checking a requirements traceability relationship}”; Parrish, ¶ [0037]); a code supplementing module, connected to the checking module (The system can “define relationships between semantically-similar acronyms, words, and/or phrases {semantically expand a proper noun in the requirements}” where “the results may be exported at step 544 as a merged requirements file 546 {existing in the requirements document}...in a standard linking matrix format 540” which includes “the requirement’s universally unique identifier (UUID) {a requirements traceability label} and requirements text”; Parrish, ¶ [0034], [0075], [0128]), and the code supplementing module is configured to automatically generate a required requirements document according to a historical requirements document and semantic parsing (The system further detects “faulty universal unique identification numbers (UUIDs)”, “incorrectly formatted hierarchy values (ex. 1-2 instead of 1.)”, and “faulty description columns”. As well, the system can iteratively link a “parent to its children and vice versa for requirements within a hierarchical document,” where “duplicate UUIDs or faulty hierarchy values are flagged for the user and a failed traceability alert is issued”; Parrish, ¶ [0118]).
Regarding claim 12, Parrish discloses wherein the process module comprises: a conformity evaluation unit, configured to check the consistency between the several upper-level requirements and the corresponding lower-level requirements thereof (“The RAAM Traceability tool provides the user with the functionality to accurately trace and document requirements for complex systems engineering projects {establishing a conformity evaluation system}” to “understand how high-level requirements... are transformed into lower-level requirements” by “identifying and ensuring that relationships between different layers of information (e.g., engineering artifacts) are satisfied”; Parrish, ¶ [0116]-[0117]); a natural language processing unit, connected to the conformity evaluation unit, wherein the natural language processing unit is configured to construct a requirement statement model from the several upper-level requirements and the corresponding lower-level requirements thereof (“RAAM Traceability tool include extracting requirements from Excel spreadsheets into a digitized serialized format, automated matching of similar-meaning requirements based on NLP-based document similarity analysis, generation of linking tables or merged files, and creation, population, and usage of domain models” to document “relationships between many kinds of development artifacts, e.g., system or software requirements, specification statements, designs, models and prototypes, testing protocols and test data, developed system or software components, etc.”; Parrish, ¶ [0116]-[0117]), an extraction unit, connected to the natural language processing unit, wherein the extraction unit is configured to extract a core content of the requirement statement model (The system includes “automated matching of similar-meaning requirements based on NLP-based document similarity analysis” where determining a similar meaning is the extraction of a core concept; Parrish, ¶ [0017]); and a parsing unit, connected to the extraction unit, wherein the parsing unit is configured to perform syntax parsing, semantic parsing and classifier parsing on the core content of the requirement statement model (Further discloses “requirement extraction and serialization capability includes, for example, detection of faulty universal unique identification numbers (UUIDs) {classifier parsing}, detection of incorrectly formatted hierarchy values (ex. 1-2 instead of 1.) {syntax parsing}, and detection of faulty description columns {semantic parsing}” and further “iteratively links parent to its children and vice versa for requirements within a hierarchical document.”; Parrish, ¶ [0118]), and give a final parsing result (“The tool also enables the optional creation of a summarized view of the results of the requirements quality analysis. “; Parrish, ¶ [0134]).
Regarding claim 13, Parrish discloses wherein in the conformity evaluation unit, the consistency between the several upper-level requirements and the corresponding lower-level requirements thereof is the consistency between entities and behaviors of the entities described by the several upper-level requirements and the corresponding lower-level requirements thereof (“The RAAM Traceability tool provides the user with the functionality to accurately trace and document requirements for complex systems engineering projects {establishing a conformity evaluation system}” to “understand how high-level requirements... are transformed into lower-level requirements” by “identifying and ensuring that relationships between different layers of information (e.g., engineering artifacts) are satisfied” where the system judges consistency at both the entities which define exemplary artifacts (e.g., “designs, models and prototypes,” and “developed system or software components”) and the behaviors of those entities (e.g., “system or software requirements” in light of “testing protocols and test data”) to determine consistency.; Parrish, ¶ [0116]-[0117]).
Regarding claim 14, Parrish discloses wherein the core content of the requirement comprises a subject (As shown in the example of FIG. 8, “the architecture shall support real-time situational awareness across all modules”, the core content of a requirement comprises the subject (e.g., “The architecture”); Parrish, ¶ [0078], FIG. 8), an object (Relying on the same example, the core content of a requirement comprises the object (e.g., “real-time situational awareness”).; Parrish, ¶ [0078], FIG. 8) and a syntactical relationship formed by subject-verb-object (Relying on the same example, the core content of a requirement comprises the syntactical relationship formed by subject-verb-object (e.g., “shall support” being the verb which establishes the action or state which the subject must adhere to with respect to the object).; Parrish, ¶ [0078], FIG. 8) and a quantity relationship formed by subject-keyword-object of the requirement statement (Relying on the same example, the core content of a requirement comprises a quantity relationship formed by the subject-keyword-object of the requirement statement (e.g., “across all modules/components” where the architecture is the implied subject, across acts as a key word indicating scope or distribution, and “all modules/components” is the object specifying the extent of the “Real-time situational awareness”); Parrish, ¶ [0078], FIG. 8).
Regarding claim 16, Parrish discloses wherein the checking module compares the requirement tr