Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This is the initial office action based on the application filed on April 08th, 2024, which claims 1-20 are presented for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, 10 and 16 are in independent form.
Priority
4. No priority has been considered for this application.
Information Disclosure Statement
5. Information disclosure statement filed on 04/08/2024, has been reviewed and considered by Examiner.
The Office's Note:
6. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner.
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.
7. Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1, claim 10 and claim 16 recite “generating a list of algorithms configurable with a requested software code function provided by a client device, wherein the list of algorithms is based on evaluating a plurality of software policies; generating the requested code function based on a selected algorithm of the list of algorithms” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The additional elements ““memory”, and “processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, and “transmitting the requested code function to the client device” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering, displaying, updating, transmitting and storing data/information. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(g).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of ““memory,” and “processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, and “transmitting the requested code function to the client device”, the courts have identified merely gathering, displaying, updating, transmitting and storing data/information on a display is well-understood, routine and conventional activity. See MPEP 2106.05(d). The recitation of generic computer instruction and computer components to apply the judicial exception, and merely displaying data do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
In conclusion, claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
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.
8. Claims 1-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Krishnan (US 20170277518 – hereinafter Krishnan) and further in view of Schumacher (US 12,253,932– hereinafter Schumacher).
Claim 1 rejected, Krishnan teaches a computer-implemented method comprising:
generating a list of algorithms configurable with a requested software code function provided by a client device, wherein the list of algorithms is based on evaluating a plurality of software policies (Krishnan, US 20170277518, fig. 1, component 106 – Tool, component 110 – Code solutions, component 116 – Coding options, and para [0027-0028], the tool 106 can also use the recognized characteristics to identify various coding options 116 and present the various coding options 116 for selection within a code template 114 on a user device. For instance, the coding options 116 can reflect the latest and most commonly used design patterns and/or best practices. A design pattern can be created and made available by a particular programming platform and can comprise a reusable solution to a commonly occurring problem within a given programming context. A best practice can also be created and made available by a particular programming platform and can comprise rules that the development community has learned over time which can help improve the quality of computer programs.);
generating the requested code function based on a selected algorithm of the list of algorithms and using a repository of reusable code samples in a plurality of programming languages(Krishnan, para [0027-0028], As an example, the coding options 116 in FIG. 1 are associated with different code available to handle transient connectivity issues for “BlobClient”. In a specific example, a first option may be associated with a transient fault handling block (e.g., an option implemented in association with Microsoft® Azure® services) and a second option may be associated with a circuit breaker handling block (e.g., also an option implemented in association with Microsoft® Azure® services). Therefore, the coding options 116 can provide different solutions to address a same or similar issue, where each solution has advantages and disadvantages to consider depending on the design architecture of the computer program (e.g., as illustrated in the diagram). In some examples, a description of the features associated with a coding option may also be displayed to help the developer make a decision on which option to select. In some instances the tool 106 is configured to recommend a coding option (e.g., order the coding options displayed so that the first ordered coding option is a recommended option and the subsequent ordered coding options displayed are alternative options, provide a visual distinction that identifies a recommended coding option, etc.). Upon selection of an option (e.g., a user click on “HERE”), the tool 106 further imports additional code associated with the selected option into the code template 114. Para [0029].); and
transmitting the requested code function to the client device (Krishnan, para [0029], Consequently, via the use of code templates 112, 114 associated with the identified characteristics that are presented to a developer, structured code solutions 110 can be efficiently finalized and verified. That is, a developer is not required to generate or write the code from scratch but rather review code templates that are pre-populated with source code, update the pre-populated source code, and/or make a selection of coding options 116 so that the code solutions 110 can be finalized.).
The Office would like to use prior art Schumacher to back up Krishnan to further teach limitation
using a repository of reusable code samples in a plurality of programming languages(Schumacher, US 12,253,932, column25, line 21 to 46, Candidate solution generator 206 can include any combination of hardware and software for producing potential solutions to the test problems. Candidate solution generator 206 can generate computer code in any particular computer language, based on the boilerplate 224 and according to test problem 226 descriptions or specifications. Candidate solution generator 206 can include algorithms, heuristics, and machine learning techniques to generate candidate solutions that can be evaluated and tested, such as using test cases 204 (e.g., specific inputs and outputs to test the computer code of the candidate solution 208). Candidate solution generator 206 can generate or synthesize code, instructions, parameters and configurations, and any other artifacts of a computer code solution. The candidate solution generator 206 can use historical data, training datasets of various computer code, predefined templates, and optimization strategies to improve the quality and diversity of generated candidate solutions 208. Candidate solution generator 206 can output candidate solutions 208 in any computer language or format, based on the test problem 226 specifications. For example, by generating and testing multiple candidate solutions 208, the candidate solutions generator 206 can utilize test cases 204 and code evaluator 270 to test the performance (e.g., execution speed or efficiency) of the candidate solutions 208 to identify a candidate solution 208 that is the most effective and efficient for further development and deployment.)
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Schumacher into Krishnan to generate a client solution for the first stage at the client device. The test cases are provided to evaluate the client solution for the first stage. The client data structure is received from the client device with the client solution including a client computer code generated at the client device for the first stage. The second data structures are provided to the client device, based on determining that the client solution satisfies the validity condition for a second stage of the test problem. as suggested by Schumacher (See abstract and conclusion).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Krishnan and Schumacher teach the computer-implemented method of claim 1, further comprising: creating a unit-test associated with the requested code function, wherein the unit-test indicates a performance of the requested code function (Schumacher, column 5, line 28 to 49, The one or more processors can be configured to determine a level of performance of the client solution for the first stage, based on at least one of: an output value of a runtime of the client solution, a time of completion of the runtime, a memory usage of the runtime, or a measure of a code quality of the client solution. The one or more processors can be configured to generate, based on the level of performance for the first stage, a description for a second stage of the test problem. The client solution is a first version of the client solution for the first stage. The one or more processors are configured to receive, from the client device, during a time period for generating the client solution for the first stage, a second version of the client solution for the first stage to evaluate using the one or more first test cases. The second version can be generated prior to completion of the first version of the client solution. The one or more processors can be configured to generate, using the second version of the client solution and the one or more first test cases, an evaluation of the second version of the client solution. The one or more processors can be configured to provide, to the client device, the evaluation of the second version during the time period.).
Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Krishnan and Schumacher teach the computer-implemented method of claim 2, wherein transmitting the requested code function to the client device comprises transmitting the requested code function, the unit-test, a status message indicating whether creation of the requested code function is successful, and a data structure indicating compliant software policies of the plurality of software policies(Krishnan, para [0029], Consequently, via the use of code templates 112, 114 associated with the identified characteristics that are presented to a developer, structured code solutions 110 can be efficiently finalized and verified. That is, a developer is not required to generate or write the code from scratch but rather review code templates that are pre-populated with source code, update the pre-populated source code, and/or make a selection of coding options 116 so that the code solutions 110 can be finalized. Para [0051], At 316, once code templates that are part of a code solution are reviewed, updated, and/or approved by the user, the code solution is verified. For example, the tool 106 can analyze the syntax and semantics of the code solution and determine that the code solution will execute properly. In some implementations, the tool 106 uses an application programming interface (API) to interact with an external programming platform 240 to verify the code solution. Schumacher, column 5, line 28 to 49, The one or more processors can be configured to determine a level of performance of the client solution for the first stage, based on at least one of: an output value of a runtime of the client solution, a time of completion of the runtime, a memory usage of the runtime, or a measure of a code quality of the client solution. The one or more processors can be configured to generate, based on the level of performance for the first stage, a description for a second stage of the test problem. The client solution is a first version of the client solution for the first stage. The one or more processors are configured to receive, from the client device, during a time period for generating the client solution for the first stage, a second version of the client solution for the first stage to evaluate using the one or more first test cases. The second version can be generated prior to completion of the first version of the client solution. The one or more processors can be configured to generate, using the second version of the client solution and the one or more first test cases, an evaluation of the second version of the client solution. The one or more processors can be configured to provide, to the client device, the evaluation of the second version during the time period. Column 30, line 63 to column 31, line 13, Code evaluator 270 can include any combination of hardware and software for analyzing and assessing the performance, operation, correctness, or quality of computer code of any candidate solutions 208 or client solutions 212. Code evaluator 270 can evaluate the computer code based on the validity conditions 272, such as particular performance parameters. For example, validity conditions 272 can include any performance metrics according to test cases 204 or metrics on code execution. Code evaluator 270 can perform static and dynamic code analysis to identify issues such as bugs, inefficiencies, and security vulnerabilities. Code evaluator 270 can use a variety of tools and techniques, including linting, code review, and automated testing, to evaluate code quality. Code evaluator 270 can integrate with the solution execution environment and code recorder to access and analyze code artifacts. Code evaluator 270 can generate reports that provide insights into code quality and suggest improvements. Column 36, line 4 to 22. Column 84, line 46 to 56, The text-based results can be stored in a text-based form (e.g., a report 264) that can include a section header for each of the evaluation parameters 262 (e.g., analysis dimensions assessed). The summary section of the report 264 can provide a summary of the analyses, whereas individual evaluation parameter sections (e.g., sections on algorithm design, language proficiency, and debugging) can be minimized as to not overwhelm the user with information. Each section corresponding to each evaluation parameter 262 can include a header that the admin user can select to expand or minimize the section.).
Claim 4 is rejected for the reasons set forth hereinabove for claim 1, Krishnan and Schumacher teach the computer-implemented method of claim 1, wherein the plurality of software policies are respectively associated with a precedence (Krishnan, para [0041], The coding option module 224 is configured to identify a portion of code in a code template 238 that is associated with multiple different coding options. To determine the different coding options, the coding option module 224 can interact with various programming platforms 240 hosted by devices and/or resources of the service provider(s) 204. For example, the coding options can be associated with design patterns and/or best practices that may be applicable to a computer program based on the specific design architecture (e.g., based on the components and characteristics recognized in the diagram). In various implementations, service provider 202 and service provider 204 can be the same service provider. Para [0061], the coding options presented in the code template 504 can be a subset of a larger set of coding options 506 made available via the programming platform 240. Moreover, the coding options 506 can be evaluated and ordered based on their applicability to the characteristics of a particular design architecture.).
Claim 5 is rejected for the reasons set forth hereinabove for claim 4, Krishnan and Schumacher teach the computer-implemented method of claim 4, wherein a policy resolver is implemented to generate the list of algorithms and based on evaluating respective precedencies of the plurality of software policies (Krishnan, para [0061], the coding options presented in the code template 504 can be a subset of a larger set of coding options 506 made available via the programming platform 240. Moreover, the coding options 506 can be evaluated and ordered based on their applicability to the characteristics of a particular design architecture. That is, the first coding option presented in the display area 518 may correspond to the recommended coding option stored in the datastore 508, the second coding option presented in the display area 518 may correspond to the first alternative recommended coding option stored in the datastore 508, and the third coding option presented in the display area 518 may correspond to the second alternative recommended coding option stored in the datastore 508. These first three coding options can be recommended in a particular order, as shown. However, the datastore 508 may also include a fourth coding option that is “not recommended” and/or a fifth coding option that would be “incompatible” with a particular design architecture. Based on the evaluation, the fourth coding option and/or the fifth coding option are not presented within the code template 504 for selection by a user.).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Krishnan and Schumacher teach the computer-implemented method of claim 1, wherein the plurality of software policies comprises an organization policy, a developer policy, an environment administrator policy, a machine policy, and a client policy(Krishnan, para [0027], the tool 106 can also use the recognized characteristics to identify various coding options 116 and present the various coding options 116 for selection within a code template 114 on a user device. For instance, the coding options 116 can reflect the latest and most commonly used design patterns and/or best practices. A design pattern can be created and made available by a particular programming platform and can comprise a reusable solution to a commonly occurring problem within a given programming context. A best practice can also be created and made available by a particular programming platform and can comprise rules that the development community has learned over time which can help improve the quality of computer programs. Para [0041], the coding options can be associated with design patterns and/or best practices that may be applicable to a computer program based on the specific design architecture (e.g., based on the components and characteristics recognized in the diagram). Para [0053], the coding options can be associated with design patterns and/or best practices that may be applicable to a computer program based on the specific design architecture (e.g., based on the components and characteristics recognized in the diagram)).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Krishnan and Schumacher teach the computer-implemented method of claim 1, wherein the repository of reusable code samples in the plurality of programming languages is generated using an Artificial Intelligence (AI) model, and wherein the AI model creates the requested code function that is compliant with the plurality of software policies using the repository of the reusable code samples(Krishnan, para [0027], the tool 106 can also use the recognized characteristics to identify various coding options 116 and present the various coding options 116 for selection within a code template 114 on a user device. For instance, the coding options 116 can reflect the latest and most commonly used design patterns and/or best practices. A design pattern can be created and made available by a particular programming platform and can comprise a reusable solution to a commonly occurring problem within a given programming context. A best practice can also be created and made available by a particular programming platform and can comprise rules that the development community has learned over time which can help improve the quality of computer programs. ).
Claim 8 is rejected for the reasons set forth hereinabove for claim 1, Krishnan and Schumacher teach the computer-implemented method of claim 1, wherein the plurality of software policies comprises a machine policy, and wherein the machine policy is generated by implementing performance benchmarks against an associated computational environment with compatible software functions exhibiting relatively higher performance than incompatible software functions in the machine policy(Krishnan, para [0061], the coding options presented in the code template 504 can be a subset of a larger set of coding options 506 made available via the programming platform 240. Moreover, the coding options 506 can be evaluated and ordered based on their applicability to the characteristics of a particular design architecture. That is, the first coding option presented in the display area 518 may correspond to the recommended coding option stored in the datastore 508, the second coding option presented in the display area 518 may correspond to the first alternative recommended coding option stored in the datastore 508, and the third coding option presented in the display area 518 may correspond to the second alternative recommended coding option stored in the datastore 508. These first three coding options can be recommended in a particular order, as shown. However, the datastore 508 may also include a fourth coding option that is “not recommended” and/or a fifth coding option that would be “incompatible” with a particular design architecture. Based on the evaluation, the fourth coding option and/or the fifth coding option are not presented within the code template 504 for selection by a user.).
As per claim 10, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 11, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the system claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the system claim to method claim 4 and claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the system claim to method claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the system claim to method claim 8. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the medium claim to method claim 4 and claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the medium claim to method claim 6 and claim 8. Therefore, it is rejected for the same reasons as above.
9. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Krishnan (US 20170277518 – hereinafter Krishnan), in view of Schumacher (US 12,253,932– hereinafter Schumacher) and further in view of Venkateswaran (US 20200234346 – hereinafter Venkateswaran).
Claim 9 is rejected for the reasons set forth hereinabove for claim 1, Krishnan and Schumacher teach the computer-implemented method of claim 1, wherein the computer-implemented method is executed by a computational system based on software function generator code downloaded to the computational system from a remote data processing system, and wherein the computer-implemented method further comprises:
metering usage of the software function generator code (Venkateswaran, US 20200234346, para [0040], Application code complexity-based cloud metering engine 218 utilizes final application code complexity score 248 to generate Platform as a Service metering metric 250. Platform as a Service metering metric 250 represents the service price that data processing system 200 charges the Software as a Service provider for executing the Software as a Service application associated with source code 222.); and
generating an invoice based on metering the usage of the software function generator code(Venkateswaran, para [0040], Application code complexity-based cloud metering engine 218 utilizes final application code complexity score 248 to generate Platform as a Service metering metric 250. Platform as a Service metering metric 250 represents the service price that data processing system 200 charges the Software as a Service provider for executing the Software as a Service application associated with source code 222.).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Venkateswaran into Krishnan and Schumacher to determine metering metric for software as service application based on complexity of software as service application as suggested by Venkateswaran (See abstract and conclusion).
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199