Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 of this title, 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
Claims 1, 2, 4, 7-9, 11, 14-16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Waxman et al. (US 2024/0338306, hereinafter Waxman) in view of Johns et al. (US 2016/0314301, hereinafter Johns).
Regarding claim 1, Waxman discloses
A computer-implemented method for automated generation of application programming interfaces (APIs) for accessing services in cloud computing environments, the method being executed by one or more processors and comprising (fig. 1-4):
receiving, by a … code analyzer, API metadata descriptive of an API (paragraph [0038]: At 302, a specification file of an API is received) that is to be deployed to a cloud computing environment to enable access to a service (paragraph [0044]: At 314, in response to successfully validating the API source code using the tests, the source code of the API is deployed to an environment that was selected in the specification file);
processing, by the … code analyzer, the API metadata to retrieve source code that encodes functionality of the service and process the source code to generate a code structure that is descriptive of the source code (paragraph [0042]: At 310, a source code of the API and test(s) corresponding to the source code are generated by using the template. Generating the source code of the API can include generating a parameterized predefined code from the template and modifying the parameterized code to replace parameters based on the values included in the specification file);
generating, by an API generator, boilerplate code and … (paragraph [0042]: Health checks are done as part of boilerplate code generation) for the API using the API metadata and the code structure (paragraph [0042]: At 310, a source code of the API and test(s) corresponding to the source code are generated by using the template. Generating the source code of the API can include generating a parameterized predefined code from the template and modifying the parameterized code to replace parameters based on the values included in the specification file); and
deploying the API to the cloud computing environment (paragraph [0021]: cloud computing environments; paragraph [0044]: At 314, in response to successfully validating the API source code using the tests, the source code of the API is deployed to an environment that was selected in the specification file).
Waxman does not disclose static code analyzer … glue code.
Johns discloses static code analyzer … glue code (fig. 1-4, paragraph [0017]: For static analysis, a model of the source code is built, on which the static analysis is performed … A parse tree is built, which is a precise representation of the original code … The abstract syntax tree (AST) disposes of the additional data and simplifies the representation of the source code constructs; paragraph [0051]: the glue code 104 is the use case specific part of the analysis. In some examples, the glue code 104 is created for each use case and required results… Depending on the use case, the DSCA module 100 and/or the SSCA module 102 may also be extended; paragraph [0052]: the glue code 104 accesses the APIs provided by the DSCA module 100 and/or the SSCA module 102 to use their specific functionalities. In this manner, the glue code 104 is able to determine the order in which static and dynamic analysis are performed… For example, the glue code 104 could first access the API of the DSCA module 100, which extracts certain code that is subsequently sent to the SSCA module 102. The SSCA module 102 examines the code, requests runtime values of variables and continues the analysis).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Waxman’s template-driven API generation and validation system with Johns’ known SSCA components and glue-code coordination. The motivation would have been to combine SSCA and DSCA to complement each other and provide improved analysis results (e.g., less false positives, less false negatives) (Johns paragraph [0043]).
Regarding claim 8 referring to claim 1, Waxman discloses A non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations for automated generation of application programming interfaces (APIs) for accessing services in cloud computing environments, the operations comprising: … (fig. 1-4; par. 7; a non-transitory computer-readable storage medium…).
Regarding claim 15 referring to claim 1, Waxman discloses A system, comprising: a computing device; and a computer-readable storage device coupled to the computing device and having instructions stored thereon which, when executed by the computing device, cause the computing device to perform operations for automated generation of application programming interfaces (APIs) for accessing services in cloud computing environments, the operations comprising: … (fig. 1-4; par. 5-7; a system includes… memory… processor…API…).
Regarding claims 2, 9, and 16, Waxman does not disclose wherein the code structure is generated by: providing, by a tokenizer of the static code analyzer, a set of tokens from the source code; generating, by a parser of the static code analyzer, a syntax tree using the set of tokens; and defining, by an analyzer, the code structure from the syntax tree.
Johns discloses wherein the code structure is generated by: providing, by a tokenizer of the static code analyzer, a set of tokens from the source code (paragraph [0017]: The model that is built for the analysis contains only important information. Any unnecessary characters such as whitespaces, comments and brackets are removed. A parse tree is built, which is a precise representation of the original code. During the build process of the parse tree, additional information may be added … The abstract syntax tree (AST) disposes of the additional data and simplifies the representation of the source code constructs; paragraph [0073]: In some examples, the static analysis module includes a syntax tree builder … In some examples, before the syntax tree is built, the underlying code is provided to a third-party module, which reformats minified code to make the code easier to read for constructing the syntax tree, and make the location information more precise; Note: Johns expressly describes preprocessing and parse-tree/AST construction. Tokenization (lexical analysis) is an inherent step immediately preceding parse-tree construction. Johns’ discussion of removing non-syntactic characters and preparing code for the syntax tree reflects that standard tokenization step); generating, by a parser of the static code analyzer, a syntax tree using the set of tokens (paragraph [0017]: A parse tree is built … The abstract syntax tree (AST) disposes of the additional data and simplifies the representation of the source code constructs … ; paragraph [0073]: the static analysis module includes a syntax tree builder … which builds a syntax tree based on the code that is sent by the first extension; Note: Johns explicitly teaches a parser component (“syntax tree builder”) that builds a syntax tree for static analysis); and defining, by an analyzer, the code structure from the syntax tree (paragraph [0017]: The abstract syntax tree (AST) … simplifies the representation of the source code constructs. Consequently, the static analysis can be performed more easily and quickly; paragraph [0073]: … and a tree traverser … which traverses the syntax tree to retrieve the desired information (e.g., determining out which identifiers occur in the code); paragraph [0074]: Depending on the required information, the traversing code … is implemented … to traverse the syntax tree … until all paths are traversed and all desired information is collected; Note: Johns’ “tree traverser” functions as the analyzer operating over the syntax tree to derive a descriptive “code structure” (e.g., identifiers, paths, structural relationships) used for subsequent static analysis).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Waxman’s template-driven API generation/validation system with Johns’ well-known SSCA tokenizer/parser/AST/traverser. The motivation would have been to combine SSCA and DSCA to complement each other and provide improved analysis results (e.g., less false positives, less false negatives) (Johns paragraph [0043]).
Regarding claims 4, 11, and 18, Waxman discloses
wherein generating, by an API generator, boilerplate code and … (paragraph [0042]: Health checks are done as part of boilerplate code generation) for the API comprises reading the code structure generated by the … code analyzer and the API metadata, and combining at least a portion of the code structure and at least a portion of the API metadata (paragraph [0038]: At 302, a specification file of an API is received; paragraph [0042]: At 310, a source code of the API and test(s) corresponding to the source code are generated by using the template. Generating the source code of the API can include generating a parameterized predefined code from the template and modifying the parameterized code to replace parameters based on the values included in the specification file).
Waxman does not disclose static code analyzer … glue code.
Johns discloses static code analyzer … glue code (paragraph [0017]: For static analysis, a model of the source code is built, on which the static analysis is performed … A parse tree is built, which is a precise representation of the original code … The abstract syntax tree (AST) disposes of the additional data and simplifies the representation of the source code constructs; paragraph [0051]: the glue code 104 is the use case specific part of the analysis. In some examples, the glue code 104 is created for each use case and required results… Depending on the use case, the DSCA module 100 and/or the SSCA module 102 may also be extended; paragraph [0052]: the glue code 104 accesses the APIs provided by the DSCA module 100 and/or the SSCA module 102 to use their specific functionalities. In this manner, the glue code 104 is able to determine the order in which static and dynamic analysis are performed… For example, the glue code 104 could first access the API of the DSCA module 100, which extracts certain code that is subsequently sent to the SSCA module 102. The SSCA module 102 examines the code, requests runtime values of variables and continues the analysis).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Waxman’s template-driven API generation and validation system with Johns’ known SSCA components and glue-code coordination. The motivation would have been to combine SSCA and DSCA to complement each other and provide improved analysis results (e.g., less false positives, less false negatives) (Johns paragraph [0043]).
Regarding claims 7 and 14, Waxman discloses
wherein deploying the API to the cloud computing environment is performed (paragraph [0021]: cloud computing environments; paragraph [0044]: At 314, in response to successfully validating the API source code using the tests, the source code of the API is deployed to an environment that was selected in the specification file) in response to validating the API (paragraph [0043]: At 312, the source code of the API is validated using the test(s).).
Claims 3, 5, 6, 10, 12, 13, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Waxman et al. (US 2024/0338306, hereinafter Waxman) in view of Johns et al. (US 2016/0314301, hereinafter Johns) as applied to claims 1, 8, and 15, and further in view of Jain et al. (US 2015/0186193, hereinafter Jain).
Regarding claims 3, 10, and 17, Waxman in view of Johns does not disclose wherein the set of tokens comprises a list of objects representing categorized input characters.
Jains discloses wherein the set of tokens comprises a list of objects representing categorized input characters (paragraph [0027] The descriptive content 108 may describe the source code 106 and/or the API of the service provider …the descriptive content 108 may be in a particular format, such as … structured format (e.g., extensible markup language (XML); paragraph [0043]: Here, the source code 202 may be analyzed to identify characteristics that relate to routines and/or data constructs of the service provider. This may include identifying terms that relate to a routine, a characteristic of a routine (e.g., a parameter of the routine, a type of the parameter, an order of multiple parameters of the routine, or a type of return of the routine), a data construct, and/or a characteristic of a data construct (e.g., a data field, such as an attribute that describes an object), and so on. For example, a lexer may tokenize the source code 202 into tokens and subsequently a parser may interpret the tokens based on rules that specify a structure of a programming language; paragraph [0062] At 702, the provider 102 may analyze source code that is related to an API of a service provider and/or content that describes the source code and/or the API of the service provider. In one example, the analysis may include utilizing techniques such as NLP or other textual analysis to identify a term in the content that relates to at least one of a routine of the source code, a characteristic of a routine, a data construct, and/or a characteristic of a data construct. In another example, the analysis may tokenize the source code into tokens and parse the tokens to identify a term in the source code that relates to at least one of a routine of the source code, a characteristic of a routine, a data construct, and/or a characteristic of a data construct. In yet another example, the analysis may include utilizing a binary analysis, statistics, and so on).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Waxman’s API-generator/specification teachings with Johns’ SSCA parse-tree/AST and glue-code coordination and to use Jain’s lexer/parser to provide token objects as input to Johns’ syntax-tree builder. The motivation would have been to facilitate to identify a term in the source code that relates to at least one of a routine of the source code, a characteristic of a routine, a data construct, and/or a characteristic of a data construct (Jains paragraph [0062]).
Regarding claims 5, 12, and 19, Waxman discloses
wherein the API metadata is stored in … file and comprises a protocol (paragraph [0050]: he specification file form can be a standard form used by an open-source tool (e.g., Swagger API) built to help programmers to … use REST APIs), a language (paragraph [0038]: The specification file can be formatted using a human-readable language including a language-independent format (e.g., JavaScript Object Notation (JSON), Yaml, Ruby, Python, and VBScript) that can be used with any programming language or a particular programming language), a path (paragraph [0031]: the specification file 200 includes multiple values, such as … an identifier of a target environment 206), and a source code mapping (paragraph [0042]: Generating the source code of the API can include generating a parameterized predefined code from the template and modifying the parameterized code to replace parameters based on the values included in the specification file).
Waxman in view of Johns does not disclose wherein the API metadata is stored in an extensible markup language (XML) file.
Jains discloses wherein the API metadata is stored in an extensible markup language (XML) file (service provider …the descriptive content 108 may be in a particular format, such as … structured format (e.g., extensible markup language (XML); paragraph [0043]: Here, the source code 202 may be analyzed to identify characteristics that relate to routines and/or data constructs of the service provider. This may include identifying terms that relate to a routine, a characteristic of a routine (e.g., a parameter of the routine, a type of the parameter, an order of multiple parameters of the routine, or a type of return of the routine), a data construct, and/or a characteristic of a data construct (e.g., a data field, such as an attribute that describes an object), and so on. For example, a lexer may tokenize the source code 202 into tokens and subsequently a parser may interpret the tokens based on rules that specify a structure of a programming language; paragraph [0062] At 702, the provider 102 may analyze source code that is related to an API of a service provider and/or content that describes the source code and/or the API of the service provider. In one example, the analysis may include utilizing techniques such as NLP or other textual analysis to identify a term in the content that relates to at least one of a routine of the source code, a characteristic of a routine, a data construct, and/or a characteristic of a data construct. In another example, the analysis may tokenize the source code into tokens and parse the tokens to identify a term in the source code that relates to at least one of a routine of the source code, a characteristic of a routine, a data construct, and/or a characteristic of a data construct. In yet another example, the analysis may include utilizing a binary analysis, statistics, and so on). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to represent Waxman’s disclosed API specification/metadata by Jain’s structured, machine-readable file format such as XML to facilitate automated processing by code generators and analyzers. Using XML to encode protocol, target language, endpoint/path information, and source-code mapping is a straightforward implementation of Waxman’s specification-driven generation and would have been expected by a skilled practitioner to enable parsers, tokenizers, and generator modules to interoperate. Further, combining Johns’ teachings of static source-code analysis (AST/parse tree construction and traversal) and glue-code coordination with Waxman’s specification-driven generator would benefit from storing metadata in a structured, parseable format (e.g., XML) so that Johns’ analysis modules and Waxman’s generator could programmatically read the same metadata and code-structure mappings.
Regarding claim 6, 13, and 20, Waxman discloses
wherein the source code is retrieved based on the source code mapping (paragraph [0042]: At 310, a source code of the API and test(s) corresponding to the source code are generated by using the template. Generating the source code of the API can include generating a parameterized predefined code from the template and modifying the parameterized code to replace parameters based on the values included in the specification file).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Burgazzoli et al. (US 2023/0385140) discloses “The tool may create the definition file 106 by analyzing (e.g., parsing) any suitable data structure, such as a GoLang file, a YAML file, a JSON file, or a source code file written in a programming language … A definition file 106 created in this way can specify which API are to be deployed and monitored by the second operator software 108” (paragraph [0027]).
Caspi (US 10,169,035) discloses “FIG. 3 depicts an example system 100 for static code analysis according to one or more embodiments. The system includes a source code analysis system 120 that analyzes the source code 110 of a computer program product, such as an enterprise application, or any other software product” (col. 7, lines 36-40) and “A definition file 106 created in this way can specify which API are to be deployed and monitored by the second operator software 108” (col. 7, lines 61-65).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7: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, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 3/15/2026