DETAILED ACTION
This action is responsive to the amendments filed 8/28/2026.
Claims 1-20 are pending. Claims 1, 8 and 15 are currently amended.
The prior rejection under 35 U.S.C. § 103 are maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which a joint inventor regards as the invention.
Each of the independent claims recites the limitation "generating pseudo-code or code based on the inputs that define the parameters of the commands." There is insufficient antecedent basis for this limitation in the claim. Each claim previously recites operations or a method step of, “receiving one or more inputs that define a parameter or parameters of the commands.” Therefore, “the inputs” and “the parameters” do not have proper antecedent basis in the claims, as they are previously recited as “one or more,” and do not necessarily encompass plural inputs or plural parameters.
Additionally, each of the independent claims recites one or more inputs that “define a parameter or parameters of the commands.” This renders the claim indefinite, as the broadest reasonable interpretation includes that the “parameter” is not related to the commands, and it is not clear whether this reflects what a joint inventor regards as the invention. Examiner suggests amending this limitation to read, “define one or more parameters of the commands,” to more clearly delineate that defining a single parameter means defining a parameter of the commands.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bahrami, et al., U.S. PGPUB No. 2021/0216288 (“Bahrami”), in view of Childs, et al., U.S. Patent No. 9,430,194 (“Childs”).
With regard to Claim 1, Bahrami teaches a system comprising:
a memory; and at least one hardware processor coupled to the memory and comprising instructions (Fig. 2 and [0048]) that causes the system to perform operations comprising:
causing display of a graphical user interface (GUI) that comprises one or more interface elements that correspond with a function or commands ([0148] describes that a business object is selected in an interface, causing display of associated policies, limitations, and legacy which can be updated by the user. [0068] describes that business objects encapsulates conditions applicable on a set of input/output parameters associated with a corresponding API call object);
receiving one or more inputs that define a parameter or parameters of the commands ([0068] describes that the business objects define conditions for values of parameters for use and access of an API endpoint, as well as restrictions on the use of the parameters themselves);
Bahrami, in view of Childs teaches generating pseudo-code or code based on the inputs that define the parameters of the commands; and causing display of the pseudo-code or code within the GUI.
Bahrami teaches inputs that defines the parameters of the commands, as described above. [0160] teaches that configured business objects can be compiled into a software product, where [0132] describes that the user selections generate the source code for compiling. Childs teaches at Col. 15, lines 32-52 that a user operating a development environment and making selections for generating source code can also enable an option to generate and display pseudocode of the generated source code.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Childs with Bahrami. Childs describes at Col. 21, line 62 – Col. 22, line 15 that pseudocode can aid developers in performing high-level step tracing, and that simplified views free up screen real estate during debugging. Therefore, one of skill in the art would have been motivated to introduce a pseudocode display, to improve user experience by aiding in step-tracing and other code debugging activities.
Claim 8 recites a method which is carried out by the system of Claim 1, and is similarly rejected. Claim 15 recites a medium storing instructions which are executed to implement the system of Claim 1, and is likewise rejected.
With regard to Claim 2, Childs teaches that the interface element further comprises a plurality of interface elements that comprise a sequence, and wherein the generating the segment of the pseudo-code is based on the sequence of the plurality of interface elements. Col. 14, line 63 – Col. 15, line 31 describe that a user can select an element in a sequential display of code elements, such as variable definitions, to enable a pseudocode view. As shown at Figs. 6A – 6B, these elements appear in the sequence in the pseudocode of Fig. 6B that they appear in the first view in Fig. 6A.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Childs with Bahrami. Childs describes at Col. 21, line 62 – Col. 22, line 15 that pseudocode can aid developers in performing high-level step tracing, and that simplified views free up screen real estate during debugging. Therefore, one of skill in the art would have been motivated to introduce a pseudocode display, to improve user experience by aiding in step-tracing and other code debugging activities.
Claim 9 recites a method which is carried out by the system of Claim 2, and is similarly rejected. Claim 16 recites a medium storing instructions which are executed to implement the system of Claim 2, and is likewise rejected.
With regard to Claim 3, Bahrami teaches a user input received via a menu that displays a set of parameters, as [0128] describes that the business layer includes user selectable options related to conditions applicable on the set of input/output parameters. Bahrami does not specifically teach that the menu is a drop-down menu. Examiner takes official notice that a drop-down menu was well-known in the art at the time this application was filed as a way to present selectable options to a user.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine this well-known element with Bahrami and Childs. This is a simple substitution of one known element for selecting things in an interface – the drop-down menu – for the display of selectable elements described in Bahrami, with the predictable result of presenting the selectable elements in the form of a drop-down menu.
Claim 10 recites a method which is carried out by the system of Claim 3, and is similarly rejected. Claim 17 recites a medium storing instructions which are executed to implement the system of Claim 3, and is likewise rejected.
With regard to Claim 4, Bahrami teaches configuring the command based on the parameter defined by the input. [0068] describes that the business objects include conditions. [0070] describes that business object rules can be used to configure commands, such as by defining a maximum number of scans allowed for a particular scan command.
Claim 11 recites a method which is carried out by the system of Claim 4, and is similarly rejected. Claim 18 recites a medium storing instructions which are executed to implement the system of Claim 4, and is likewise rejected.
With regard to Claim 5, Bahrami teaches accessing a repository that comprises a plurality of code extensions; selecting a code extension from among the plurality of code extensions based on the parameter of the command. [0071]-[0072] describe that generated business objects are packaged along with the other elements such that a user interface for an object-oriented platform can be generated. [0146]-[0149] describe that business objects are loaded into an interface, where one of the plurality of objects is selectable and configurable from among the displayed objects. Therefore, an existing segment of code is selected based on the parameter, as the object a user selects will have been selected for the purpose of using the desired parameters.
Bahrami, in view of Childs teaches generating the pseudo-code based on the code extension. Bahrami at [0160] teaches that configured business objects can be compiled into a software product, where [0132] describes that the user selections generate the source code for compiling. Childs teaches at Col. 15, lines 32-52 that a user operating a development environment and making selections for generating source code can also enable an option to generate and display pseudocode of the generated source code.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Childs with Bahrami. Childs describes at Col. 21, line 62 – Col. 22, line 15 that pseudocode can aid developers in performing high-level step tracing, and that simplified views free up screen real estate during debugging. Therefore, one of skill in the art would have been motivated to introduce a pseudocode display, to improve user experience by aiding in step-tracing and other code debugging activities.
Claim 12 recites a method which is carried out by the system of Claim 5, and is similarly rejected. Claim 19 recites a medium storing instructions which are executed to implement the system of Claim 5, and is likewise rejected.
With regard to Claim 6, Bahrami, in view of Childs teaches that a position of the code extension within the pseudo code corresponds with a sequence of interface elements that include the interface element within the GUI.
Bahrami at [0160] teaches that configured business objects can be compiled into a software product, where [0132] describes that the user selections generate the source code for compiling. Childs teaches at Col. 14, line 63 – Col. 15, line 31 that a user can select an element in a sequential display of code elements, such as variable definitions, to enable a pseudocode view. As shown at Figs. 6A – 6B, these elements appear in the sequence in the pseudocode of Fig. 6B that they appear in the first view in Fig. 6A.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Childs with Bahrami. Childs describes at Col. 21, line 62 – Col. 22, line 15 that pseudocode can aid developers in performing high-level step tracing, and that simplified views free up screen real estate during debugging. Therefore, one of skill in the art would have been motivated to introduce a pseudocode display, to improve user experience by aiding in step-tracing and other code debugging activities.
Claim 13 recites a method which is carried out by the system of Claim 6, and is similarly rejected. Claim 20 recites a medium storing instructions which are executed to implement the system of Claim 6, and is likewise rejected.
With regard to Claim 7, Bahrami teaches configuring an API endpoint based on the function. [0156]-[0160] describes that API call objects are accessed in the interface, where these objects along with the business objects are compiled into a software component. [0035] describes that API call objects invokes a call for a particular endpoint, according to unique values of input/output parameters.
Claim 14 recites a method which is carried out by the system of Claim 7, and is similarly rejected.
Response to Arguments
Applicant's arguments have been fully considered but they are not persuasive. Applicant first argues with regard to Claim 1 that Bahrami does not teach the specific flow of receiving multiple inputs to generating code based on those inputs.
However, as is described in the rejection, the inputs described in Bahrami are used to generate code. [0160] describes that the configured business objects - which are configured by user input as described at [0148] – are compiled into a software product. [0132] specifically describes a UI through which a user develops a software application through selection of objects and modifying of the object properties, and that the process produces source code that can be compiled to generate the software application. Therefore, Bahrami does generate code from user-selected parameters.
Applicant then argues that the motivation for combining the references is “generic” and lacks rational underpinning. Applicant alleges that the motivation would be to include a pseudo-code display in any GUI-based interface. Applicant further alleges that the motivation fails to explain why a person of ordinary skill in the art would integrate parameter inputs from a menu into a code generation pipeline.
Examiner submits that this argument ignores a fundamental underpinning of the rejection, which is that Bahrami already teaches code generation. As is cited in the rejection, [0132] of Bahrami describes that code is generated from the user inputs to the UI. Additionally, [0088] states that “the processor may also generate a program code for the API connector in a suitable programming language.” [0089] further describes that the system can produce code for specific target computing environments. Bahrami is not merely a GUI in which a user makes selections, but rather Bahrami describes an object-oriented development environment for generating application source code.
Therefore, Bahrami teaches the architecture and sequence of operations. Bahrami is silent on the aspect of displaying the source code to the user, and does not disclose the provision of pseudo-code. It is only this aspect of Claim 1 that Childs is relied upon for teaching. The motivation is not based on including a pseudo-code display along with any GUI; rather, the motivation rests on the benefit of providing the pseudo-code display of Childs in an environment in which source code is generated in response to user inputs to a GUI as taught in Bahrami. It is notable that Childs also teaches an environment where users generate code by making selections in a GUI, making Childs and its benefits and improvements particularly relevant to the systems and methods described in Bahrami.
As the references are properly relied upon as teaching or suggesting the elements of the claims, as described in both the above rejection and these remarks, the prima facie finding of obviousness has not been rebutted and the rejections are properly maintained. As the dependent claims have not been challenged separate from their dependence from the independent claims, they likewise remain properly rejected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEITH D BLOOMQUIST whose telephone number is (571)270-7718. The examiner can normally be reached M-F, 8:30-5 PM.
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, Kieu Vu can be reached at 571-272-4057. 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.
/KEITH D BLOOMQUIST/Primary Examiner, Art Unit 2171
9/18/2026
Prosecution Insights