DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed December 4, 2024.
Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/4/2024, 2/5/2025, 4/16/2025 was filed after the mailing date of the application on 12/4/2024Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 respectively of U.S. Patent No.12,164,887. Although the claims at issue are not identical, they are not patentably distinct from each other because the pending claims are obvious in view of the patented claims as aligned below.
. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Application 18/968,894
US Patent 12,164,887
1. A computing system comprising: at least one hardware processor; and at least one non-transitory memory carrying instructions that, when executed by the at least one hardware processor, cause the computing system to: receive at least one message that describes a desired software architecture comprising at least one telecommunication resource; extract from the at least one message at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or a phrase; identify, based on the extracted at least one entity and using a trained machine learning model, multiple recommended standards-related requirements for the desired software architecture; configure for display the multiple recommended standards-related requirements for the desired software architecture; receive a selection of one or more of the multiple recommended standards-related requirements; and generate the desired software architecture, wherein the desired software architecture includes a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements.
2. The computing system of claim 1, wherein the at least one message includes a requirements statement or at least a portion of a software requirements specification (SRS).
3. The computing system of claim 1, wherein the at least one non-transitory memory further carries instructions to: convert the at least one message into a requirements statement in a standard format, wherein the requirements statement specifies a function or feature of the software architecture, and wherein the at least one message includes two or more of: a role, a starting condition, an exception, a requirement, or an acceptance criterion.
4. The computing system of claim 1: wherein configuring to display the multiple recommended standards-related requirements for the desired software architecture comprises configuring a graphical user interface (GUI) that includes a deployment region, and wherein the selection of the one or more recommended standards-related requirements is received by detecting that a user has dragged the one or more recommended standards-related requirements to the deployment region.
5. The computing system of claim 1: wherein configuring to display the multiple recommended standards-related requirements for the desired software architecture comprises configuring a graphical user interface (GUI) comprising a first input field to receive the message and a second input field to receive an additional message, wherein the second input field is displayed in response to receiving a command to add an input field, and wherein the displayed multiple recommended standards-related requirements dynamically update in response to receiving the additional message at the second input field.
6. The computing system of claim 1: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein each of the multiple existing standards-related requirements in the training dataset is associated with metadata.
7. The computing system of claim 1: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein at least some of the multiple existing standards-related requirements in the training dataset are associated with telecommunication resources that are represented as data objects.
8. A computer-implemented method, comprising: receiving a set of plain language messages that describe one or more requirements of a desired deployment comprising multiple telecommunication resources; extracting, from the set of plain language messages that describe the one or more requirements of the desired deployment, at least one keyword or phrase related to a characteristic of the desired deployment; accessing multiple existing telecommunication resources, wherein each of the multiple existing telecommunication resources is associated with metadata related to an existing deployment that includes the existing telecommunication resource; generating, by a trained machine learning model, a relevance score for each of the accessed multiple existing telecommunication resources, wherein the relevance score reflects a likelihood that a corresponding existing telecommunication resource is relevant to the desired deployment; recommending, based on the generated relevance scores, at least some of the multiple existing telecommunication resources for inclusion in the desired deployment, wherein one or more telecommunication resources of the at least some of the multiple existing telecommunication resources are configured to fulfill a standards-related requirement; receiving a selection of two or more telecommunication resources from the recommended at least some of the multiple existing telecommunication resources; and generating, using the selected two or more telecommunication resources, a set of instructions intended to achieve the desired deployment.
9. The method of claim 8, wherein the desired deployment includes a digital resource that represents a hardware resource associated with the desired deployment, the method further comprising: converting the set of plain language messages into at least one requirements statement in a standard format.
10. The method of claim 8, wherein the set of plain language messages is received at an input region of a graphical user interface (GUI), the method further comprising: configuring for display the recommended at least some of the multiple existing telecommunication resources at a recommendation region of the GUI.
11. The method of claim 8, further comprising: configuring for display the recommended at least some of the multiple existing telecommunication resources at a recommendation region of graphical user interface (GUI), wherein receiving the selection of the two or more telecommunication resources from the recommended at least some of the multiple existing telecommunication resources includes detecting that a user has dragged the two or more telecommunication resources from the recommendation region of the GUI to a deployment region of the GUI.
12. The method of claim 8, wherein at least some of the multiple existing telecommunication resources are accessed using data objects that each represent an existing telecommunication resource of the at least some of the multiple existing telecommunication resources.
13. The method of claim 8: wherein the desired deployment includes a software product comprising a set of microservices, and wherein generating the set of instructions intended to achieve the desired deployment includes aggregating software code.
14. The method of claim 8, further comprising: identifying a need for at least one additional telecommunication resource for the desired deployment that is not included in the multiple existing telecommunication resources; and generating a prompt to provide the needed at least one additional telecommunication resource.
15. The method of claim 8, wherein accessing the multiple existing telecommunication resources includes: accessing a data source included in the multiple existing telecommunication resources; and generating at least one data object representation of the data source or data in the data source.
16. The method of claim 8, wherein accessing the multiple existing telecommunication resources includes identifying access credentials and a location for at least a portion of the multiple existing telecommunication resources.
17. A computer-implemented method comprising: configuring for display an input region and a recommendation region, wherein the input region includes at least one input field; receiving, via the at least one input field in the input region, a plain language message that describes a desired software architecture comprising at least one microservice; extracting, from the plain language message that describes the desired software architecture, at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or phrase; identifying, based on the extracted at least one entity and using a machine learning model, multiple recommended standards-related requirements for the desired software architecture; configuring to display the multiple recommended standards-related requirements for the desired software architecture at the recommendation region; receiving, a selection of one or more of the multiple recommended standards-related requirements, wherein the selected one or more standards-related requirements are associated with a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements; and generating the desired software architecture, wherein the desired software architecture includes the set of telecommunication resources configured to fulfill the selected one or more standards-related requirements.
18. The method of claim 17, further comprising: configuring for display a deployment region, wherein the selection of the one or more recommended standards-related requirements is received by detecting that a user has dragged the one or more recommended standards-related requirements to the deployment region.
19. The method of claim 17, further comprising: configuring to display an input region including at least one input field comprising a first input field to receive the plain language message and a second input field to receive an additional message, wherein the second input field is displayed in response to receiving a command to add an input field; and configuring to dynamically update the multiple recommended standards-related requirements in response to receiving the additional message at the second input field.
20. The method of claim 17: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein at least some of the multiple existing standards-related requirements in the training dataset are associated with telecommunication resources that are represented as data objects.
1. A computing system for generating software architectures requirements based on standards-related requirements, the computing system comprising: at least one hardware processor; at least one display; and at least one non-transitory memory carrying instructions that, when executed by the at least one hardware processor, cause the computing system to perform operations to generate a software architecture based on one or more standards-related requirements, the operations comprising: displaying, at the at least one display, a graphical user interface (GUI) that includes at least one input field; receiving, via the at least one input field, at least one message that describes a desired software architecture, wherein the desired software architecture comprises at least one telecommunication resource; extracting, from the at least one message that describes the desired software architecture, at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or a phrase; identifying, based on the extracted at least one entity and using a trained machine learning model, multiple recommended standards-related requirements for the desired software architecture, wherein the multiple recommended standards-related requirements are identified based on comparing a relevance score generated by the machine learning model for each of a plurality of standards- related requirements to a corresponding threshold relevance score, and wherein the multiple recommended standards-related requirements relate to one or more of a privacy standard, a legal standard, or a security standard applicable to the desired software architecture; dynamically displaying, at the GUI, the multiple recommended standards- related requirements for the desired software architecture; receiving a selection of one or more of the multiple recommended standards- related requirements, wherein the selected one or more standards-related requirements are associated with a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements; and generating, by the computing system, the desired software architecture, wherein the desired software architecture includes the set of telecommunication resources configured to fulfill the selected one or more standards-related requirements.
2. The computing system of claim 1, wherein the at least one message includes a requirements statement or at least a portion of a software requirements specification (SRS).
3. The computing system of claim 1, wherein the operations further comprise: converting the at least one message into a requirements statement in a standard format, wherein the requirements statement specifies a function or feature of the software architecture, and wherein the at least one message includes two or more of: a role, a starting condition, an exception, a requirement, or an acceptance criterion.
4. The computing system of claim 1: wherein the GUI includes a deployment region, and wherein the selection of the one or more recommended standards-related requirements is received by detecting that a user has dragged the one or more recommended standards-related requirements to the deployment region.
5. The computing system of claim 1: wherein the at least one input field of the GUI comprises a first input field to receive the message and a second input field to receive an additional message, wherein the second input field is displayed in response to receiving a command to add an input field, and wherein the displayed multiple recommended standards-related requirements dynamically update in response to receiving the additional message at the second input field.
6. The computing system of claim 1: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein each of the multiple existing standards-related requirements in the training dataset is associated with metadata.
7. The computing system of claim 1: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein at least some of the multiple existing standards-related requirements in the training dataset are associated with telecommunication resources that are represented as data objects.
8. At least one computer-readable medium, excluding transitory signals, carrying instructions that, when executed by a computing system, cause the computing system to perform operations to generate a deployment using existing telecommunication resources, the operations comprising: receiving a set of plain language messages that describe one or more requirements of a desired deployment comprising multiple telecommunication resources; extracting, from the set of plain language messages that describe the one or more requirements of the desired deployment, at least one keyword or phrase related to a characteristic of the desired deployment; accessing multiple existing telecommunication resources, wherein the multiple existing telecommunication resources comprise at least one of a data source, a microservice, or a communication channel, and wherein each of the multiple existing telecommunication resources is associated with metadata related to an existing deployment that includes the existing telecommunication resource; generating, by a trained machine learning model, a relevance score for each of the accessed multiple existing telecommunication resources, wherein the relevance score reflects a likelihood that a corresponding existing telecommunication resource is relevant to the desired deployment; recommending, based on the generated relevance scores, at least some of the multiple existing telecommunication resources for inclusion in the desired deployment, wherein one or more telecommunication resources of the at least some of the multiple existing telecommunication resources are configured to fulfill a standards-related requirement; receiving a selection of two or more telecommunication resources from the recommended at least some of the multiple existing telecommunication resources; and generating, using the selected two or more telecommunication resources, a set of instructions intended to achieve the desired deployment.
9. The at least one computer-readable medium of claim 8, wherein the desired deployment includes a digital resource that represents a hardware resource associated with the desired deployment, the operations further comprising: converting the set of plain language messages into at least one requirements statement in a standard format.
10. The at least one computer-readable medium of claim 8, wherein the set of plain language messages is received at an input region of a graphical user interface (GUI), the operations further comprising: displaying the recommended at least some of the multiple existing telecommunication resources at a recommendation region of the GUI.
11. The at least one computer-readable medium of claim 8, the operations further comprising: displaying the recommended at least some of the multiple existing telecommunication resources at a recommendation region of graphical user interface (GUI), wherein receiving the selection of the two or more telecommunication resources from the recommended at least some of the multiple existing telecommunication resources includes detecting that a user has dragged the two or more telecommunication resources from the recommendation region of the GUI to a deployment region of the GUI.
12. The at least one computer-readable medium of claim 8, wherein at least some of the multiple existing telecommunication resources are accessed using data objects that each represent an existing telecommunication resource of the at least some of the multiple existing telecommunication resources.
13. The at least one computer-readable medium of claim 8: wherein the desired deployment includes a software product comprising a set of microservices, and wherein generating the set of instructions intended to achieve the desired deployment includes aggregating software code.
14. The at least one computer-readable medium of claim 8, wherein the operations further comprise: identifying a need for at least one additional telecommunication resource for the desired deployment that is not included in the multiple existing telecommunication resources; and generating a prompt to provide the needed at least one additional telecommunication resource.
15. The at least one computer-readable medium of claim 8, wherein accessing the multiple existing telecommunication resources includes: accessing a data source included in the multiple existing telecommunication resources; and generating at least one data object representation of the data source or data in the data source.
16. The at least one computer-readable medium of claim 8, wherein accessing the multiple existing telecommunication resources includes identifying access credentials and a location for at least a portion of the multiple existing telecommunication resources.
17. At least one computer-readable medium, excluding transitory signals, carrying instructions that, when executed by a computing system, cause the computing system to perform operations to generate software architecture requirements, the operations comprising: displaying a graphical user interface (GUI) comprising an input region and a recommendation region, wherein the input region of the GUI includes at least one input field; receiving, via the at least one input field in the input region of the GUI, a plain language message that describes a desired software architecture, wherein the desired software architecture comprises at least one microservice; extracting, from the plain language message that describes the desired software architecture, at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or phrase; identifying, based on the extracted at least one entity and using a machine learning model, multiple recommended standards-related requirements for the desired software architecture, wherein the multiple recommended standards-related requirements for the software architecture are identified based on comparing a relevance score generated by the machine learning model for each of a plurality of existing standards-related requirements to a corresponding threshold relevance score, and wherein the multiple recommended standards-related requirements relate to one or more of a privacy standard, a legal standard, or a security standard applicable to the desired software architecture; dynamically displaying, at the recommendation region of the GUI, the multiple recommended standards-related requirements for the desired software architecture; receiving, via the GUI, a selection of one or more of the multiple recommended standards-related requirements, wherein the selected one or more standards-related requirements are associated with a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements; and generating, by the computing system, the desired software architecture, wherein the desired software architecture includes the set of telecommunication resources configured to fulfill the selected one or more standards-related requirements.
18. The at least one computer-readable medium of claim 17: wherein the GUI further comprises a deployment region, and wherein the selection of the one or more recommended standards-related requirements is received by detecting that a user has dragged the one or more recommended standards-related requirements to the deployment region.
19. The at least one computer-readable medium of claim 17: wherein the at least one input field of the GUI comprises a first input field to receive the plain language message and a second input field to receive an additional message, wherein the second input field is displayed in response to receiving a command to add an input field, and wherein the displayed multiple recommended standards-related requirements dynamically update in response to receiving the additional message at the second input field.
20. The at least one computer-readable medium of claim 17: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein at least some of the multiple existing standards-related requirements in the training dataset are associated with telecommunication resources that are represented as data objects.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) 8 and 17 recite processes whereas Claim 1 recites a machine (a computing system with a process and non-transitory memory). The claims are analyzed herein under the Alice test set forth in MPEP §2111.
Step 1: The claim(s) recite(s) 8 and 17 recite processes whereas Claim 1 recites a machine (a computing system with a process and non-transitory memory). Each claim a statutory category under §101 and thus pass Step 1 of the Analysis.
Step 2A Prong 1: Given their broadest reasonable interpretation, each of the independent claims recites an abstract idea, a mental process capable of being carried out in the human mind. Specifically, for example, claim 1 recites in part:” extract from the at least one message at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or a phrase;
identify, based on the extracted at least one entity and using a trained machine learning model, multiple recommended standards-related requirements for the desired software architecture;” Claims 8 and 17 recite similar limitations. The broadest reasonable interpretation of these steps, in light of the specification (e.g. Spec. ¶¶14-16) includes a person reading a description, judging standards-related requirements associated with it, and laying out a design to satisfy it, a mental process which can be achieved with aid of a pencil and paper. See MPEP §2106.04.
Step 2A Prong 2: The additional elements of these claims recite only generic computer elements and extra solution activity, and thus do not integrate the mental process described previous into a practical application. For example Claim 1 recites: A computing system comprising: at least one hardware processor;
and at least one non-transitory memory carrying instructions that, when executed by the at least one hardware processor, cause the computing system to: receive at least one message that describes a desired software architecture comprising at least one telecommunication resource;…configure for display the multiple recommended standards-related requirements for the desired software architecture; receive a selection of one or more of the multiple recommended standards-related requirements; and generate the desired software architecture, wherein the desired software architecture includes a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements.” These limitations, and similar limitations in claims 8 and 17, recite generic computer elements, including a process, memory, GUI and machine learning model laid out in generic terms, and extra solution gathering steps, as well as a generic results-only “generate” step, similar to those found ineligible in §101 Guidance. See MPEP §2106.04(d).
Step 2B: Similarly, these additional elements do not make the claim as a whole amount to significantly more than the abstract idea. The additional elements of claim 1 quoted above in Step2a prong 2, and similar limitations in claims 8 and 17 analyzed here, fail to amount to signicantly more than the mental process laid out in Step 2A prong 1, as they recite generic computer elements, extra solution activity of receiving and displaying data, and a result-only recitation of a generate step, none of which comprises significantly more than the abstract idea itself when analyzed under Step 2B. See MPEP §2106.05.
The dependent claims 2-7,9-15 and 18-20 inherit the same recitation of a mental process as the independent claims upon which they depend and are rejected on the same basis. Each of the independent claims recite only additional generic computer elements and extra solution activity which fail to integrate the abstract idea into a practical application under Step 2a prong 2. MPEP §2106.04(d). Moreover, these limitations fail to recite significantly more than the abstract idea as required under Step 2B. See MPEP §2106.05. The dependent claims, therefore, are rejected on the same basis as the independent claims herein.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Bulut” (US PG Pub 2021/0304063) in view of “Nikumb” (US PG Pub 2021/0397418)
Regarding Claim 1, Bulut teaches:
1. A computing system comprising: at least one hardware processor;(114, Fig. 1)
and at least one non-transitory memory (116 , Fig. 1)carrying instructions that, when executed by the at least one hardware processor, cause the computing system to:
extract from the at least one message at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or a phrase;( Bulut e.g. 404, Fig. 4 ¶¶34-36,52 teaches natural language processing to extract features from a received microservice using trained ML model)
identify, based on the extracted at least one entity and using a trained machine learning model, multiple recommended standards-related requirements for the desired software architecture ;( Bulut e.g. 406, Fig. 4 ¶¶36,47-52 teaches using ML model to predict regulation/standards compliance requirements from extracted features))
configure for display the multiple recommended standards-related requirements for the desired software architecture;(Bulut e.g. ¶¶37-39 describes acception/rejection of the predicted requirements by a verification manager, which may require presenting it to a subject matter expert for acception or rejection) [Inherent in the presentation to the SME is presentation of the standards-related requirements to the SME for acceptance or rejection
receive a selection of one or more of the multiple recommended standards-related requirements;( Bulut e.g. ¶¶37-39 describes acception/rejection of the predicted requirements by a verification manager, which may require presenting it to a subject matter expert for acception or rejection) [Inherent in the presentation to the SME is presentation of the standards-related requirements to the SME for acceptance or rejection
Bulut does not teach, but Nikumb teaches:
receive at least one message that describes a desired software architecture comprising at least one telecommunication resource;(Nikumb ¶15, 105, Fig. 1A 320, Fig. 3 teaches receiving requirements documents for application to be generated)
and generate the desired software architecture, wherein the desired software architecture includes a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements. (Nikumb 380, Fig. 3, ¶101 teaches generating the application code for the application based on the requirements in the process of Fig. 3)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 8, Bulut teaches:
8. A computer-implemented method, comprising:
extracting, from the set of plain language messages that describe the one or more requirements of the desired deployment, at least one keyword or phrase related to a characteristic of the desired deployment ;( Bulut e.g. 404, Fig. 4 ¶¶34-36,52 teaches natural language processing to extract features from a received microservice using trained ML model)
accessing multiple existing telecommunication resources, wherein each of the multiple existing telecommunication resources is associated with metadata related to an existing deployment that includes the existing telecommunication resource; ;( Bulut e.g. 404, Fig. 4 ¶¶34-36,52 teaches natural language processing to extract features from existing microservice using trained ML model, where model is trained using existing microservices)
recommending, … at least some of the multiple existing telecommunication resources for inclusion in the desired deployment, wherein one or more telecommunication resources of the at least some of the multiple existing telecommunication resources are configured to fulfill a standards-related requirement;( Bulut e.g. 406, Fig. 4 ¶¶36,47-52 teaches using ML model to predict regulation/standards compliance requirements from extracted features))
receiving a selection of two or more telecommunication resources from the recommended at least some of the multiple existing telecommunication resources;( ;(Bulut e.g. ¶¶37-39 describes acception/rejection of the predicted requirements by a verification manager, which may require presenting it to a subject matter expert for acception or rejection) [Inherent in the presentation to the SME is presentation of the standards-related requirements to the SME for acceptance or rejection]
Bulut does not teach, but Nikumb teaches:
receiving a set of plain language messages that describe one or more requirements of a desired deployment comprising multiple telecommunication resources ;(Nikumb ¶15, 105, Fig. 1A 320, Fig. 3 teaches receiving requirements documents for application to be generated)
generating, by a trained machine learning model, a relevance score for each of the accessed multiple existing telecommunication resources, wherein the relevance score reflects a likelihood that a corresponding existing telecommunication resource is relevant to the desired deployment;(Nikumb e.g. ¶¶23-24, 71-72,75-76,109 teaches calculating confidence scores associated with requirements document processing and extracted features )
and generating, using the selected two or more telecommunication resources, a set of instructions intended to achieve the desired deployment. (Nikumb 380, Fig. 3, ¶101 teaches generating the application code for the application based on the requirements in the process of Fig. 3)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 17, Bulut teaches:
17. A computer-implemented method comprising:
receiving, via the at least one input field in the input region, a plain language message that describes a desired software architecture comprising at least one microservice ;( Bulut e.g. 404, Fig. 4 ¶¶34-36,52 teaches natural language processing to extract features from a received microservice using trained ML model)
extracting, from the plain language message that describes the desired software architecture, at least one entity related to a characteristic of the desired software architecture, wherein the at least one entity includes a keyword or phrase;(Bulut e.g. 404, Fig. 4 ¶¶34-36,52 teaches natural language processing to extract features from a received microservice using trained ML model)
identifying, based on the extracted at least one entity and using a machine learning model, multiple recommended standards-related requirements for the desired software architecture;(Bulut e.g. 406, Fig. 4 ¶¶36,47-52 teaches using ML model to predict regulation/standards compliance requirements from extracted features)
configuring to display the multiple recommended standards-related requirements for the desired software architecture at the recommendation region;(Bulut e.g. ¶¶37-39 describes acception/rejection of the predicted requirements by a verification manager, which may require presenting it to a subject matter expert for acception or rejection) [Inherent in the presentation to the SME is presentation of the standards-related requirements to the SME for acceptance or rejection)
receiving, a selection of one or more of the multiple recommended standards-related requirements, wherein the selected one or more standards-related requirements are associated with a set of telecommunication resources configured to fulfill the selected one or more standards-related requirements;(Bulut e.g. ¶¶37-39 describes acception/rejection of the predicted requirements by a verification manager, which may require presenting it to a subject matter expert for acception or rejection) [Inherent in the presentation to the SME is presentation of the standards-related requirements to the SME for acceptance or rejection]
Bulut does not teach, but Nikumb teaches:
configuring for display an input region and a recommendation region, wherein the input region includes at least one input field;(Nikumb e.g. ¶¶33-34, Figs. 1A,1B describe a user interface including chatbot and canvas regions which take NL input and display recommended application element output data)
and generating the desired software architecture, wherein the desired software architecture includes the set of telecommunication resources configured to fulfill the selected one or more standards-related requirements. (Nikumb 380, Fig. 3, ¶101 teaches generating the application code for the application based on the requirements in the process of Fig. 3)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 2, Bulut does not teach, but Nikumb teaches:
2. The computing system of claim 1, wherein the at least one message includes a requirements statement or at least a portion of a software requirements specification (SRS). (Nikumb ¶14 teaches requirements document as an SRS) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 3, Bulut does not teach, but Nikumb teaches:
3. The computing system of claim 1, wherein the at least one non-transitory memory further carries instructions to: convert the at least one message into a requirements statement in a standard format, wherein the requirements statement specifies a function or feature of the software architecture, and wherein the at least one message includes two or more of: a role, a starting condition, an exception, a requirement, or an acceptance criterion. (Nikumb e.g. ¶¶20,38,41 translating requirements doc into structured format identifying requirements, API endpoints, response models)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 4, Bulut does not teach, but Nikumb teaches:
4. The computing system of claim 1: wherein configuring to display the multiple recommended standards-related requirements for the desired software architecture comprises configuring a graphical user interface (GUI) that includes a deployment region, and wherein the selection of the one or more recommended standards-related requirements is received by detecting that a user has dragged the one or more recommended standards-related requirements to the deployment region. (Nikumb ¶¶33-34 teaches a GUI w/ a canvas for objects to be deployed including allowing design of application GUIs and wireframes within the canvas)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 5, Bulut does not teach, but Nikumb teaches:
5. The computing system of claim 1: wherein configuring to display the multiple recommended standards-related requirements for the desired software architecture comprises configuring a graphical user interface (GUI) comprising a first input field to receive the message and a second input field to receive an additional message, wherein the second input field is displayed in response to receiving a command to add an input field, (Nikumb ¶¶33-34 teaches a GUI w/ a chatbot interface for sending and receiving multiple messages with the user) and wherein the displayed multiple recommended standards-related requirements dynamically update in response to receiving the additional message at the second input field. (Nikumb ¶¶33-34 teaches a GUI w/ a chatbot interface for sending and receiving multiple messages with the user)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 6, Bulut further teaches:
6. The computing system of claim 1: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein each of the multiple existing standards-related requirements in the training dataset is associated with metadata. (Bulut ¶¶33-34, 47-49 teaches a machine learning model training on dataset including existing microservices and associated requirements)
Regarding Claim 7, Bulut further teaches:
7. The computing system of claim 1: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein at least some of the multiple existing standards-related requirements in the training dataset are associated with telecommunication resources that are represented as data objects. (Bulut Fig. 3 310-314, ¶¶33-34, 47-49 teaches a machine learning model training on dataset including existing microservices and associated requirements)
Regarding Claim 9, Bulut does not teach, but Nikumb further teaches:
9. The method of claim 8, wherein the desired deployment includes a digital resource that represents a hardware resource associated with the desired deployment, (Nikumb e.g. ¶50-51 teaches identifying the devices on which the application will be deployed)
the method further comprising: converting the set of plain language messages into at least one requirements statement in a standard format. (Nikumb ¶20 teaches translating the requirements information into a structured xml file) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 10, Bulut does not teach, but Nikumb further teaches:
10. The method of claim 8, wherein the set of plain language messages is received at an input region of a graphical user interface (GUI), the method further comprising: configuring for display the recommended at least some of the multiple existing telecommunication resources at a recommendation region of the GUI. (Nikumb ¶¶33-34 teaches a GUI w/ a chatbot interface for sending and receiving multiple messages with the user)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
11. The method of claim 8, further comprising: configuring for display the recommended at least some of the multiple existing telecommunication resources at a recommendation region of graphical user interface (GUI), wherein receiving the selection of the two or more telecommunication resources from the recommended at least some of the multiple existing telecommunication resources includes detecting that a user has dragged the two or more telecommunication resources from the recommendation region of the GUI to a deployment region of the GUI. . (Nikumb ¶¶33-35 teaches a GUI w/ a canvas for objects to be deployed including allowing design of application GUIs and wireframes within the canvas)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 12, Bulut does not teach, but Nikumb teaches:
12. The method of claim 8, wherein at least some of the multiple existing telecommunication resources are accessed using data objects that each represent an existing telecommunication resource of the at least some of the multiple existing telecommunication resources. (Nikumb e.g. ¶32, 115 Fig. 1C teaches asset data structure storying information for reusable assets and components) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding claim 13, Bulut teaches:
13. The method of claim 8: wherein the desired deployment includes a software product comprising a set of microservices, ;( Bulut e.g. 404, Fig. 4 ¶¶34-36,52 teaches natural language processing to extract features from existing microservice using trained ML model, where model is trained using existing microservices)
Bulut does not teach, but Nikumb teaches:
and wherein generating the set of instructions intended to achieve the desired deployment includes aggregating software code.(Nikumb Fig. 1H, ¶47, 380, fig. 3, ¶101 teaches generating of code from reusable assets) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 14, Bulut does not teach, but Nikumb teaches:
14. The method of claim 8, further comprising: identifying a need for at least one additional telecommunication resource for the desired deployment that is not included in the multiple existing telecommunication resources;(Nikumb e.g. ¶50 describes a resource estimate identifying resources needed to deploy the application)
and generating a prompt to provide the needed at least one additional telecommunication resource. ;(Nikumb e.g. ¶50 describes a resource estimate identifying resources needed to deploy the application; further ¶¶33-34 describes the chatbot interface for prompting user input) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 15, Bulut does not teach, but Nikumb teaches:
15. The method of claim 8, wherein accessing the multiple existing telecommunication resources includes: accessing a data source included in the multiple existing telecommunication resources; (Nikumb e.g. ¶32, 115 Fig. 1C teaches asset data structure storying information for reusable assets and components)
and generating at least one data object representation of the data source or data in the data source. .(Nikumb Fig. 1H, ¶47, 380, fig. 3, ¶101 teaches generating of code from reusable assets) In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 16, Bulut does not teach, but Nikumb teaches:
16. The method of claim 8, wherein accessing the multiple existing telecommunication resources includes identifying access credentials and a location for at least a portion of the multiple existing telecommunication resources. (Nikumb ¶¶19,38teaches accessing a url or path for accessing a resource, and ¶16 identifying credentials to access the application). In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 18, Bulut does not teach, but Nikumb teaches:
18. The method of claim 17, further comprising: configuring for display a deployment region, wherein the selection of the one or more recommended standards-related requirements is received by detecting that a user has dragged the one or more recommended standards-related requirements to the deployment region. (Nikumb ¶¶33-34 teaches a GUI w/ a canvas for objects to be deployed including allowing design of application GUIs and wireframes within the canvas)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 19, Bulut does not teach, but Nikumb teaches:
19. The method of claim 17, further comprising: configuring to display an input region including at least one input field comprising a first input field to receive the plain language message and a second input field to receive an additional message, wherein the second input field is displayed in response to receiving a command to add an input field; (Nikumb ¶¶33-34 teaches a GUI w/ a chatbot interface for sending and receiving multiple messages with the user) and configuring to dynamically update the multiple recommended standards-related requirements in response to receiving the additional message at the second input field. (Nikumb ¶¶33-34 teaches a GUI w/ a chatbot interface for sending and receiving multiple messages with the user)
In addition, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Bulut and Nikumb as each is directed to requirements processing systems and Nikumb recognized the need for “an application generation system that utilizes natural learning understanding and machine learning to automatically generate a software application (referred to herein as an application) based on a requirements document (e.g., a request for proposal (RFP) document, a software requirements specification (SRS) document, and/or the like)” (¶11).
Regarding Claim 20, Bulut teaches;
20. The method of claim 17: wherein the machine learning model is trained using a training dataset comprising multiple existing standards-related requirements each associated with at least one existing software architecture and a corresponding set of telecommunication resources to fulfill the existing standards-related requirement, and wherein at least some of the multiple existing standards-related requirements in the training dataset are associated with telecommunication resources that are represented as data objects. (Bulut ¶¶33-34, 47-49 teaches a machine learning model training on dataset including existing microservices and associated requirements)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art cited in the attached PTO-892 form include prior art relevant to applicant’s disclosures related to systems for identifying requirements for software and generating related code.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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, Wei Zhen can be reached at 571-272-3708. 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.
MJB
9/28/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights