DETAILED ACTION
This action is responsive to Remarks and Claim Amendments filed on July 24, 2026.
Claims 1, 8 and 15 have been amended.
Claims 1-20 are pending and are presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to amendments
The objection to the abstract of the disclosure set forth in the Non-Final Office Action is withdrawn in view of the amendment to the specification filed July 24, 2026.
The objection to claims 8-20 for lack of proper antecedent basis for “the computer source code” is withdrawn in view of the amendments to claims 8 and 15.
Response to Arguments
Applicant's arguments filed July 24, 2026 have been fully considered but they are not persuasive. Examiner responds below.
Rejection under 35 U.S.C. § 101.
Applicant traverses the rejection but does not identify any error in the Examiner's analysis, relying instead on the assertion that the amendments “fully address the reasons for the rejection or otherwise render the rejection moot.” The argument is not persuasive. The amendment to claims 1, 8 and 15 adds (i) that the code generation system is “of a cloud-based storage system” and (ii) a wherein clause specifying that the computer source code being generated is code of a partner system that utilizes APIs to access services of that cloud-based storage system. Neither addition changes the character of the claim as a whole. The recited “cloud-based storage system,” “partner system” and “Application Programming Interfaces (APIs)” are not affirmatively operated upon by any recited step; they merely identify the environment in which the generated code will later be used and the entity that will later use it. Such recitations generally link the use of the judicial exception to a particular technological environment or field of use, which does not integrate the exception into a practical application and does not amount to significantly more. See MPEP § 2106.05(h). The steps that are actually performed — receiving information defining a coding node, creating the coding node, transforming it, and transpiling it — are unchanged by the amendment. The rejection is therefore maintained and is restated below to address the amended claim language.
Rejection under 35 U.S.C. § 102 over Gackenheimer.
The rejection of claims 1-4, 8-11 and 15-18 under 35 U.S.C. 102(a)(1) as anticipated by Gackenheimer is withdrawn in view of the amendment. Applicant's arguments directed to Gackenheimer are therefore moot. New grounds of rejection under 35 U.S.C. 103, necessitated by the amendment, are set forth below.
Examiner notes for the record that Applicant’s assertion that Gackenheimer “seems to be silent regarding anything that can reasonably be considered to suggest such recitation” is a general allegation that does not point out how the language of the claims patentably distinguishes them from the reference. See 37 CFR 1.111(b) and MPEP § 2145. The rejection is nevertheless withdrawn on the merits because Gackenheimer does not teach the newly added partner-system/API limitation.
Rejections under 35 U.S.C. § 103.
Applicant requests withdrawal of the rejections of claims 5-6, 12-13, 19-20 and claims 7 and 14 solely on the basis that each depends from a base claim “thought to be allowable.” Because the independent claims remain rejected for the reasons given below, the argument is not persuasive. The dependent claims are addressed on the merits below.
Specification
The specification is objected to because of the following informalities:
(a) Paragraph [0051] refers to the same element by two different reference numerals, reciting “a code generator 335 can then transform and transpile this code definition 405” and, in the same paragraph, “as may be performed by the code generator 410.”
(b) Paragraph [0052] recites “a program 5050 can comprise one or more coding nodes 510,” which appears to be a typographical error for reference numeral 505.
(c) Paragraph [0061] recites “Many modern programming languages distinct synchronous and asynchronous modes of processing,” which appears to be a typographical error for “distinguish.” The same paragraph recites “If a user calls a asynchronous function,” which appears to be a typographical error for “an asynchronous function.” (d) Paragraph [0026] recites “Erasable Programable Read-Only Memory (EPROM),” which appears to be a typographical error for “Erasable Programmable Read-Only Memory,” the term being spelled correctly earlier in the same sentence.
(e) Paragraph [0062] recites “achieving ease and\or reducing cost of implementation,” which appears to contain a typographical error.
Appropriate correction is required.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “wherein the computer source code comprises computer source code of a partner system of the cloud-based storage system utilizing Application Programming Interfaces (APIs) to access one or more services of the cloud-based storage system.” It is unclear what the participial phrase “utilizing Application Programming Interfaces (APIs) to access one or more services of the cloud-based storage system” modifies. The phrase may be read as modifying “computer source code,” such that it is the generated code that utilizes the APIs; as modifying “a partner system,” such that it is the partner system that utilizes the APIs; or, as the grammatically nearest antecedent, as modifying “the cloud-based storage system,” which would require the cloud-based storage system to utilize APIs in order to access its own services. These readings are of different scope and the claim provides no indication of which is intended. The ambiguity is confirmed by claim 8, which recites the corresponding subject matter as “the computer source code comprising code utilizing Application Programming Interfaces (APIs) to access one or more services of the cloud-based storage system,” expressly attributing the utilizing to the code rather than to the partner system or to the cloud-based storage system. Claim 1 contains no such attribution. Clarification is required.
Claim 1 further recites in the preamble “A method for automated generation of computer source code” and recites “an object tree for the computer source code,” while the final step recites “transpiling, by the processor of the code generation system, the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages.” It is unclear whether the “software source code” produced by the transpiling step is the same as “the computer source code” for which the object tree is built and which the wherein clause defines as code of a partner system utilizing APIs, or whether the two are different. The distinction is material to the scope of the claim, because if the recited “software source code” is not “the computer source code,” then the limitation imposed by the wherein clause is not imposed upon the code that the claimed method actually produces. Clarification is required.
Claims 2-7 are rejected under 35 U.S.C. 112(b) as depending from claim 1 and inheriting the same deficiencies.
Claim 8 recites “an object tree for computer source code of a partner system of the cloud-based storage system” and recites in its final limitation “transpile the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages.” Claim 8 is rejected under 35 U.S.C. 112(b) for the same reason set forth for claim 1 with respect to the relationship between “computer source code” and “software source code.” Claims 9-14 are rejected under 35 U.S.C. 112(b) as depending from claim 8 and inheriting the same deficiency.
Claim 15 recites “an object tree for computer source code of a partner system of a cloud-based storage system” and recites in its final limitation “transpile the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages.” Claim 15 is rejected under 35 U.S.C. 112(b) for the same reason set forth for claim 1 with respect to the relationship between “computer source code” and “software source code.” Claims 16-20 are rejected under 35 U.S.C. 112(b) as depending from claim 15 and inheriting the same deficiency.
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 recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into a practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-7 are directed to methods and fall within the statutory category of processes; Claims 8-14 are directed to systems and fall within the statutory category of machines; and Claims 15-20 are directed to mediums and fall within the statutory category of manufactures. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1, 8 and 15 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations:
a) “receiving, by a processor of a code generation system of a cloud-based storage system, information defining a coding node, the coding node comprising a definition of an object within an object tree for the computer source code;”
b) “creating, by the processor of the code generation system, the coding node based on the received information defining the coding node;”
c) “transforming, by the processor of the code generation system, the coding node into an intermediate, transformed coding node;”
For example, for limitations a)-c), a person using pen and paper can receive information defining a code construct, can write down a corresponding code construct representing a node or block, and can rewrite that construct into an intermediate representation. That is, nothing in the claim elements precludes the steps from practically being performed in the mind or with the aid of pen and paper, i.e., “receiving”, “creating” and “transforming” can be performed in the human mind through observation, evaluation, judgment and opinion with the aid of pen and paper.
Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas.
Therefore, Yes, claims 1, 8 and 15 recite judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
This judicial exception is not integrated into a practical application. The claims recite the following additional elements: “a processor”, “a code generation system”, “a memory”, “a cloud-based storage system”, “a partner system”, “Application Programming Interfaces (APIs)”, “a system”; and “a non-transitory, computer-readable medium”, together with the step of “transpiling, by the processor of the code generation system, the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages.”
The additional elements “a processor”, “a code generation system”, “a memory”, “a system” and “a non-transitory, computer-readable medium” are merely instructions to implement an abstract idea on a computer, or merely use a generic computer or generic computer components as a tool to perform the abstract idea (see MPEP § 2106.05(f)). The specification confirms this at paragraphs [0031]-[0032] and [0043]-[0047], which describe the hardware in wholly generic terms.
The additional elements “a cloud-based storage system”, “a partner system” and “Application Programming Interfaces (APIs)” do no more than generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP § 2106.05(h)). No recited step operates upon, transmits to, or receives from the cloud-based storage system, the partner system, or the APIs; these elements only identify where the generated source code will eventually be deployed and what it will eventually call. Confining the claimed code-generation process to the field of cloud-storage partner integrations does not impose a meaningful limit on practicing the abstract idea.
Further, “transpiling, by the processor of the code generation system, the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages” amounts to no more than mere instructions to apply the exception using a generic computer component.
Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application?” No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluated the inquiries set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 8 and 15 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into a practical application.
Step 2B:
With respect to “transpiling, by the processor of the code generation system, the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages,” when re-evaluated this element is well-understood, routine, conventional activity. As evidence, Rattray (US Pat. No. 11,709,659), Background, column 1 lines 45-58, discloses: “Traditionally, there have been two primary methods for generating code: string interpolation, and Abstract Syntax Tree (AST) building with AST-based printers.” Rattray, Background, column 1 lines 30-44, further discloses that code is generated to implement and document multiple supported client API libraries for a range of different programming languages. This is an express statement in the prior art that generating source code for multiple target programming languages by building and printing an intermediate syntax-tree representation was a long-prevailing, conventional practice. See MPEP § 2106.05(d)(II) and Berkheimer v. HP Inc. Therefore this element does not provide significantly more.
As discussed above with respect to integration of the abstract idea into a practical application, the additional elements “a processor”, “a code generation system”, “a memory”, “a system” and “a non-transitory, computer-readable medium” are generic computer components used as tools to perform the abstract idea, and the additional elements “a cloud-based storage system”, “a partner system” and “Application Programming Interfaces (APIs)” merely link the exception to a field of use. Accordingly, the additional elements recited in the claims, considered individually and as an ordered combination, cannot provide an inventive concept. Thus, the claims are not patent eligible.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception?” No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1, 8 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 2 (and similar for claims 9 and 16), it recites “wherein the information defining the coding node comprises Javascript Syntax eXtension (JSX) code,” which merely provides a detail of the type of code of the coding node that is part of the mental process identified above with respect to claims 1, 8 and 15. Moreover, claim 2 does not recite any other additional elements and for the same reasons as above with regard to integration into a practical application and whether additional elements amount to significantly more, claim 2 also fails Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into a practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 3 (and similar for claims 10 and 17), it recites “wherein the information defining the coding node further comprises user defined information,” which merely provides a detail of what the received information contains and is part of the mental process identified above with respect to claims 1, 8 and 15. Moreover, claim 3 does not recite any other additional elements and for the same reasons as above with regard to integration into a practical application and whether additional elements amount to significantly more, claim 3 also fails Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into a practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 3 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 4 (and similar for claims 11 and 18), it recites “wherein creating the coding node comprises generating one or more of: a node type; one or more node attributes; or one or more child nodes for the coding node based on the received information defining the coding node,” which merely provides details of what is written down when creating the coding node and is part of the mental process identified above with respect to claims 1, 8 and 15. Moreover, claim 4 does not recite any other additional elements and for the same reasons as above with regard to integration into a practical application and whether additional elements amount to significantly more, claim 4 also fails Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into a practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 5 (and similar for claims 12 and 19), it recites “wherein creating the coding node further comprises performing a preliminary validation on the coding node,” which merely provides a detail of an evaluation performed as part of the mental process identified above with respect to claims 1, 8 and 15; a person using pen and paper can check a written code construct for correctness. Moreover, claim 5 does not recite any other additional elements and for the same reasons as above with regard to integration into a practical application and whether additional elements amount to significantly more, claim 5 also fails Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into a practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 6 (and similar for claims 13 and 20), it recites “wherein transforming the coding node into the intermediate, transformed coding node further comprises: gathering additional information defining a context for the coding node; validating the coding node for unresolved references and anomalies; modifying the coding node based on the information defining the coding node and the object tree; and propagating one or more code characteristics from the modified coding node to the intermediate, transformed coding node,” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person using pen and paper can gather context about a written code construct, check it for unresolved references and errors, revise it, and carry a noted characteristic forward into the rewritten construct. Moreover, claim 6 does not recite any other additional elements and for the same reasons as above with regard to integration into a practical application and whether additional elements amount to significantly more, claim 6 also fails Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into a practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 6 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regards to claim 7 (and similar for claim 14), it recites “wherein transpiling the intermediate, transformed coding node into the source code in the target programming language comprises selecting a transpiler from a plurality of available transpilers based on the target programming language,” which as drafted is considered mere instructions to implement an abstract idea or other exception on a computer (see MPEP § 2106.05(f)). Moreover, claim 7 does not recite any other additional elements and for the same reasons as above with regard to integration into a practical application and whether additional elements amount to significantly more, claim 7 also fails Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into a practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 1-20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 8-12 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Rattray (US Pat. No. 11,709,659, hereinafter “Rattray” – previously presented) in view of Smith et al. (US Pub. No. 2013/0297680, hereinafter “Smith”).
In view of the rejection under 35 U.S.C. 112(b) set forth above, and in the interest of compact prosecution, the claims are examined below on the basis of the following interpretation: the “software source code” recited in the transpiling limitation is the same as “the computer source code” recited in the preamble and in the wherein clause, and the phrase “utilizing Application Programming Interfaces (APIs) to access one or more services of the cloud-based storage system” modifies “computer source code.” The prior art applied below teaches the limitations at issue under any of the interpretations identified in the rejection under 35 U.S.C. 112(b), and the rejections below are therefore not dependent upon the interpretation adopted. See MPEP § 2173.06. With respect to claim 1 (Currently Amended), Rattray teaches A method for automated generation of computer source code, the method comprising: (Rattray, Abstract, discloses: “Furthermore, the method may include generating, from the API specification, code in each of a plurality of different computer programming languages different from the first computer programming language and different from each other.” Examiner's Notes: Rattray is directed to a method of code generation that is carried out by a code generation tool, i.e., automatically and without a developer hand-writing the output, and the product of that method is computer source code. See also FIG. 2, multi-language code generator 250, and FIG. 3, processing blocks 302-306. The preamble is therefore met.)
receiving, by a processor of a code generation system [[of a cloud-based storage system]], information defining a coding node, the coding node comprising a definition of an object within an object tree for the computer source code (Rattray, column 5 lines 44-62 , discloses: “Particularly, code generation tool 220 may operate under the control of a program, routine, or the execution of instructions to execute methods or processes in accordance with embodiments of the invention to perform the operations described herein.” Rattray, column 6 line 67, discloses: “/ The variable is called “React” for JSX tooling” Rattray, Description, column 7 lines 21-24, discloses: “<Ruby.MethodCall callee=“puts” parens={false} args={[<Ruby.Literal value={message}/>]}” Rattray, column 14 lines 44-61, discloses: “Instead of using the parser to produce the AST, in embodiments, React-like Components are configured within the code generator 250 to transform input into an AST, then into the intermediate representation, and printers transform the intermediate representation to produce the output.” Examiner's notes: the code generation tool 220 of Rattray is a code generation system executed by a processor, as confirmed by column 5 lines 44-62 and by FIG. 5, which shows processor(s) 510 coupled to memory 550. What that system receives as its input is the declarative component definition reproduced at column 7 lines 21-24. That definition is the claimed “information defining a coding node”: it names an object (Ruby.MethodCall), assigns that object its properties (callee, parens, args), and nests a further object (Ruby.Literal) inside it. Column 14 lines 44-61confirms that these received component definitions are converted into an AST, i.e., an object tree, so that each component definition received is necessarily a definition of an object within that object tree, as claimed. The tree so built is the tree for the source code that Rattray ultimately emits, satisfying “for the computer source code.”)
wherein the computer source code comprises computer source code of a partner system of the [[cloud-based storage]] system utilizing Application Programming Interfaces (APIs) to access one or more services of the [[cloud-based storage]] system (Rattray, column 4 line 63 – column 5 line 13, discloses: “The client API based application 172, developed using a client API library 124, will enable the customer system 170 to interact with the CP API 122 to perform transactions, exchange messages, manage accounts, etc. and otherwise access the services of the commerce platform system 110.” Rattray, column 12 line 60 – column 13 line 4, discloses: “This code and documentation could then be distributed and used by customer system(s) 270 in their applications 272.” Examiner's notes: the source code that Rattray's generator produces is the client API library code. Column 12 line 60 – column 13 line 4 establishes that this generated code is delivered to, and becomes part of, the applications of the customer systems, which are entities separate from and served by the platform, i.e., partner systems. Column 4 line 63 – column 5 line 13 establishes what that generated code does once it is running on the partner system: it calls the platform's API (CP API 122) in order to reach the platform's services. The generated computer source code is therefore source code of a partner system that utilizes APIs to access one or more services of the platform, exactly as the wherein clause requires. Rattray's platform is a commerce platform system rather than a cloud-based storage system, and that difference alone is bracketed above and addressed through Smith below.)
creating, by the processor of the code generation system, the coding node based on the received information defining the coding node (Rattray, column 13 lines 36-40, discloses: “Flow's “type”s are used to ensure the expected arguments are obtained, and the component is:” Rattray, column 13 lines 47-54, discloses: “return ( <Group> {callee} {args.length && ‘ ’} <CommaSeparated trailing={false} spaces indent> {args} </CommaSeparated> </Group>” Examiner's notes: column 13 lines 34-54 set out how a node is actually built from what was received. The component is declared as a function of the properties it receives, and column 13 lines 47-54 shows the component returning a constructed node whose contents are assembled out of those very received properties — the received callee is placed into the node, and the received args are placed into the node's argument list. The node that results is therefore created on the basis of the received information defining it, as claimed. Column 14 lines 44-61, quoted above, confirms at a system level that the components so constructed are what the code generator turns into the AST.)
transforming, by the processor of the code generation system, the coding node into an intermediate, transformed coding node (Rattray, Description, column 15 lines 43-62, discloses: “In embodiments, the inputted API may be transformed into one or more intermediate representations through the interpretation of the coded declarative expressions based on the configuration of a code generator (e.g., code generation 250).” Examiner's notes: read together with column 14 lines 44-61, quoted above, Rattray performs two successive conversions on what it receives — first into the AST node, and then from that node into an intermediate representation. The second of those conversions is the claimed transforming step: the coding node is not printed directly, but is first converted into an intermediate form of that same node, which is what the printer later consumes. That intermediate form is the claimed “intermediate, transformed coding node.”) and
transpiling, by the processor of the code generation system, the intermediate, transformed coding node into software source code in a target programming language of a plurality of programming languages (Rattray, column 15 line 63 – column 16 line 5, discloses: “In an embodiment, a document “printer” transforms the intermediate representation into code suitable for inclusion in relevant client library(s) and/or documentation, such as one or more code snippets formatted and/or commented per the configuration of code generator 250, and the output based on the declarative statements in the input API.” Examiner's notes: the printer takes as its input the intermediate representation produced by the preceding transformation step and emits source code from it. Because the input to that step is source-level declarative code and the output is source code in another language, the operation is transpiling under the broadest reasonable interpretation. That the target language is one of a plurality is shown by Rattray's own worked examples, which generate the identical input into Ruby (column 7 line 16), JavaScript (column 8 line 11), PHP (column 9 line 60) and Java (column 11 lines 40-41), and by the Abstract's recitation of code in each of a plurality of different computer programming languages.)
Rattray is silent to disclose the bracketed portions of the above limitations, namely that the platform which hosts the code generation system, and whose services the partner system reaches through the APIs, is a cloud-based storage system; however, in an analogous art, Smith teaches:
a cloud-based storage system whose partner-authored systems utilize an application programming interface of that system to access one or more of its services. (Smith, paragraph [0022], discloses: “FIG. 1 illustrates an example diagram of a system 100 having a host server 110 of a cloud-based service/platform, collaboration workspace and/or cloud storage service with capabilities that enable that enable a third-party application to access content within a cloud-based platform in an integrated manner.” [sic] Smith, paragraph [0033], discloses: “In any of these configurations, the third-party applications 120 can communicate with the host server 110 for accessing cloud-based collaboration platform, storage and/or services in performing their functions.” Smith, paragraph [0041], discloses: “In accordance with some embodiments, a system (e.g., host server 110, or user devices 102) implementing the techniques disclosed herein is provided that enables (e.g., through a software framework, an application programming interface, a software library, and/or an agent application) the third-party application 120 to connect to the host server 110 which hosts the cloud-based platform for accessing content that is stored in the cloud (e.g., in cloud repository 130).” Smith, paragraph [0074], discloses: “In addition, the third-party application 120 can be authored by a partnering entity of the provider of the cloud-based platform.” Examiner's notes: Paragraph [0022] establishes that Smith's host server 110 is a cloud storage service, so the platform is a cloud-based storage system. Paragraph [0033] establishes that separate third-party applications reach that server in order to obtain its storage and services. Paragraph [0041] establishes the mechanism by which they do so — an application programming interface and software library furnished by the platform provider. Paragraph [0074] establishes who writes those applications: a partnering entity of the platform provider, i.e., a partner system. Smith therefore supplies precisely the bracketed subject matter absent from Rattray, and supplies it in the same relationship the claim recites: a cloud-based storage system, an API it publishes, and partner-authored code that calls that API to reach the system's services.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the teachings of Rattray, by having the platform that hosts the code generation system and whose services the partner system accesses through the APIs be a cloud-based storage system as suggested by Smith, because Rattray itself invites the substitution at Description, column 2 lines 45-55, which discloses: “That is, the code generation tool may be deployed for code generation in various environments, and is not limited to the commerce platform system environment discussed herein.” Rattray thus expressly states that its generator is not tied to the commerce platform and is meant to be applied to other platforms, and Smith's cloud-based storage system is such a platform, publishing to partner-authored systems the same kind of API and software library that Rattray's generator exists to produce client code for. Applying Rattray's generator to Smith's platform would predictably deliver the very benefit Rattray identifies — automatically producing and updating accurate, readable client API code in every supported programming language from one declarative source — and would thereby avoid the burden Rattray describes in its Background, column 1 lines 30-44, where making a single API change “requires unique and different changes to each of the individual API libraries”, a process Rattray characterizes as technically challenging, time consuming, and error prone.)
With respect to claim 2 (Orignal), Rattray teaches wherein the information defining the coding node comprises Javascript Syntax eXtension (JSX) code (Rattray, column 14 line 62 – column 15 line 21, discloses: “The code generator 250, in embodiments, may be implemented in JSX syntax, FLOW, or other declarative languages.” Examiner's notes: Rattray names JSX expressly as the syntax in which its node definitions are written, and the worked examples bear this out — the definitions at (column 7 line 4 - column 12 lines 41) are JSX elements, column 6 line 67 refers to JSX tooling, and column 13 lines 36-40 adds a component in a file named php.jsx. The information defining the coding node in Rattray therefore comprises JSX code, as claimed.)
With respect to claim 3 (Original), Rattray teaches wherein the information defining the coding node further comprises user defined information (Based on paragraph [0057] of the instant application, “user defined information” is manually defined information supplementing the JSX code, and the specification does not otherwise limit the term, making the requirement broad. Rattray, column 10 lines 12-20, discloses: “It can also be used in places where a hard coded string is needed, such as to replace callee=“echo” with callee={< >echo</>}, and would work the same.” Rattray, column 13 lines 5-17, discloses: “In embodiments, when not compilable, the code is output for further modification.” Examiner's notes: column 10 lines 12-20 shows a developer placing a hand-written literal string directly inside the node definition, so that the information defining the node consists partly of the declarative construct and partly of manually supplied content. Column 13 lines 5-17 shows the complementary practice on the output side, where generated code is handed back to developers who supply the remainder by hand. Either disclosure meets the broad claim term under the interpretation the specification supports.)
With respect to claim 4 (Original), Rattray teaches wherein creating the coding node comprises generating one or more of: a node type; one or more node attributes; or one or more child nodes for the coding node based on the received information defining the coding node (Rattray,column 7 lines 34-37, discloses: “<Ruby.MethodCall callee=“puts” parens={false} args={[<Ruby.Literal value={message}/>]}” Examiner's notes: this single disclosure supplies all three alternatives of the claim, only one of which is required. Ruby.MethodCall is the node type. The named properties callee, parens and args are node attributes. The nested Ruby.Literal element is a child node of the Ruby.MethodCall node. All three are generated out of the received definition itself. Rattray's Java example at column 10 line 51 – column 11 line 35 shows the same structure at greater depth, nesting Java.MethodDefinition inside Java.Class and Java.MethodCall inside Java.Statements.)
With respect to claim 5 (Original), Rattray teaches wherein creating the coding node further comprises performing a preliminary validation on the coding node (Rattray, column 13 lines 36-40, discloses: “Flow's “type”s are used to ensure the expected arguments are obtained, and the component is:” Rattray, column 13 lines 60-61, discloses: “Furthermore, tests may be added to code generator 250 to ensure that the output wanted is the output obtained:” Examiner's notes: the check described in column 13 lines 36-40 is performed on the node at the moment the component is constructed from its received properties, and it verifies that those properties are the expected ones before any transformation or printing occurs. A check applied at node-creation time and before the later processing stages is a preliminary validation on the coding node within the meaning of the claim. Column 13 lines 60-61evidences a further verification layer applied to the same components.)
With respect to claim 8 (Currently Amended), the claim recites limitations similar to claim 1, differs only in that it recites A cloud-based storage system comprising: a processor; and a memory coupled with and readable by the processor and storing therein a set of instructions which, when executed by the processor, causes the processor to: perform the recited operations, and is otherwise rejected for the same reasons set forth for claim 1 above. As to the differing limitations, Rattray teaches a processor; and a memory coupled with and readable by the processor and storing therein a set of instructions which, when executed by the processor, causes the processor to:. (Rattray, column 17 lines 21-37, discloses: “The system further comprises a random access memory (RAM) or other volatile storage device 550 (referred to as memory), coupled to bus 515 for storing information and instructions to be executed by processor(s) 510.” Examiner's notes: column 17 lines 21-37recites the memory as coupled to the processor and as holding the instructions the processor executes, which is the claimed processor-and-memory arrangement; Column 5 lines 44-62 confirms that it is the code generation tool that is so implemented. As to A cloud-based storage system, Smith teaches this element for the same reasons and with the same motivation set forth for claim 1 above.)
With respect to claims 9-12, the claims recite limitations similar to claims 2-5, respectively, and are rejected for the same reasons set forth for claims 2-5 above.
With respect to claim 15 (Currently Amended), the claim recites limitations similar to claim 1, differs only in that it recites A non-transitory, computer-readable medium comprising a set of instructions stored therein which, when executed by a processor, causes the processor to: perform the recited operations, and is otherwise rejected for the same reasons set forth for claim 1 above. As to the differing limitation, Rattray teaches A non-transitory, computer-readable medium comprising a set of instructions stored therein which, when executed by a processor, causes the processor to:. (Rattray, column 3 lines 35-46, discloses: “Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.” Examiner's notes: each medium Rattray lists is a tangible article that retains the stored instructions, and is therefore non-transitory; the instructions so stored are the instructions the processor executes to carry out the disclosed method.)
With respect to claims 16-19, the claims recite limitations similar to claims 2-5, respectively, and are rejected for the same reasons set forth for claims 2-5 above.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rattray (US Pat. No. 11,709,659, hereinafter “Rattray” – previously presented) in view of Smith et al. (US Pub. No. 2013/0297680, hereinafter “Smith”) and further in view of Bailey et al. (US Pat. No. 10,552,128, hereinafter “Bailey”).
With respect to claim 6 (Original), Rattray in view of Smith is silent to disclose; however, in an analogous art, Bailey teaches:
gathering additional information defining a context for the coding node (Bailey, column 10 lines 8-32, discloses: “A syntax tree or a set of syntax trees provide(s) a representation of the functions in the source code, the nodes of the trees corresponding to functions and the branches or hierarchy of the tree representing relationships and dependencies between various functions in the source code.” Bailey, column 10 lines 33-43, discloses: “Abstract syntax trees may be searched for call expression nodes, for example. Call expression nodes correspond to function calls.” Examiner's notes: what Bailey collects before it acts on a node is information the node does not carry on its face — which other nodes it depends on and which depend on it. Column 10 lines 8-32 states that the branches and hierarchy of the tree are used to represent those relationships and dependencies, and column 10 lines 33-43 states that the tree is searched for the call expression nodes that embody them. Determining how a given node stands in relation to the rest of the tree is the gathering of additional information defining a context for that node, as claimed.)
validating the coding node for unresolved references and anomalies (Bailey, column 6 lines 13-58, discloses: “A function is unsafe when executing the function is likely to produce an error due to a deviation from a specific sequence of job processing that the function relies on. For example, a first function may require a value be returned from a second function. Thus, until the second function is executed and resolved, and the value returned as input to the first function, the first function cannot be successfully executed.” Examiner's explanation: the condition Bailey tests for is a node whose required input has not yet been supplied by the node it calls — a reference that is not resolved at the time the node is reached — and Bailey flags that condition as one that is likely to produce an error. Bailey therefore examines each node and marks those that carry unresolved references and error-producing irregularities, which is the claimed validating step. Column 10 lines 44-53 supplies the mechanism, each function being checked by name against an index of unsafe functions.)
modifying the coding node based on the information defining the coding node and the object tree (Bailey, column 10 lines 33-43, discloses: “The source code for unsafe functions may then be re-encoded using asynchronous functions and the modification of the source code may be performed in the syntax tree itself, before the syntax tree is decompiled, for example.” Bailey, column 11 lines 3-26, discloses: “In an embodiment that parses the source code into syntax trees, each of the syntax trees is modified by removing portions of the source code corresponding to the plurality of functions determined to rely on synchronous processing and/or by encoding one or more asynchronous functions into the source code for the plurality of functions.” Examiner's notes: the modification in Bailey is made to the node in place, within the tree, and not to a flat text file — column 10 lines 33-43 is explicit that it is performed in the syntax tree itself. What drives the modification is both the node's own content, since it is the node's identified function that determines whether and how it is re-encoded, and the node's position in the tree, since column 10 line 54 – column 11 line 2 shows that a node is rewritten because of the dependency relationships the tree records. The claimed modifying based on the information defining the coding node and the object tree is therefore met.) and
propagating one or more code characteristics from the modified coding node to the intermediate, transformed coding node (Bailey, column 10 line 54 – column 11 line 2, discloses: “In some embodiments, when the method determines that a function relies on synchronous processing, the method 300 also identifies any parent functions for that function. In such an example, the parent function inherently relies on synchronous processing of the child thread, at least partially. The parent function is marked as an unsafe function that relies on synchronous processing in such an embodiment. The method continues by performing an iterative search for functions, parent functions, parents of parents, parents of parents of parents, etc.” Bailey, column 11 lines 3-26, discloses: “In embodiments that parse the source code into syntax trees, the method 300 decompiles the syntax trees, as modified, into a new version of the source code.” Examiner's notes: the characteristic at issue is synchronous versus asynchronous execution. Column 10 line 54 – column 11 line 2 shows that characteristic being carried outward from the node where it was found: once a node is determined to have it, the parent node is marked with it, then the parent of that parent, iteratively to the nth degree. That is propagation of a code characteristic from the modified node through the tree, and it is the same operation the instant specification describes at paragraph [0061], where asynchronous processing is stated to propagate from a called function to the calling function. Column 11 lines 3-26 then shows that the tree carrying those propagated marks is the tree that is decompiled into the resulting code, so the propagated characteristic is carried into the transformed representation and not merely recorded, as the claim requires.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the teachings of Rattray in view of Smith, by gathering context for the coding node, validating it for unresolved references and anomalies, modifying it within the object tree, and propagating a code characteristic from the modified node into the intermediate, transformed node as suggested by Bailey, because both Rattray and Bailey operate on the same data structure for the same purpose. Bailey states at column 7 lines 7-17: “The rewriting or re-encoding of the source code is performed automatically by a custom-built transpiler, for example.” Bailey's operations are therefore performed by the same kind of tool Rattray employs and upon the same kind of syntax tree Rattray builds. Incorporating Bailey's dependency-aware analysis would further supply Rattray's generator with something Rattray's own detection stage lacks: Rattray detects a defect only after code has been emitted, at FIG. 4 processing block 410, whereas Bailey identifies at the tree stage every node whose behavior must change because of a node it depends on, and rewrites all of them together. A person of ordinary skill would have been motivated to make that change in order to keep the generated client libraries correct across the dependent constructs of each target language, since Bailey teaches that failing to carry the characteristic to every dependent node results in failure of the application.
With respect to claim 13, the claim recites limitations similar to claim 6 and is rejected for the same reasons set forth for claim 6 above.
With respect to claim 20, the claim recites limitations similar to claim 6 and is rejected for the same reasons set forth for claim 6 above.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rattray (US Pat. No. 11,709,659, hereinafter “Rattray” – previously presented) in view of Smith et al. (US Pub. No. 2013/0297680, hereinafter “Smith”) and further in view of Gore et al. (US Pat. No. 10,733,303, hereinafter “Gore” – previously presented).
With respect to claim 7 (Original), Rattray in view of Smith is silent to disclose; however, in an analogous art, Gore teaches wherein transpiling the intermediate, transformed coding node into the source code in the target programming language comprises selecting a transpiler from a plurality of available transpilers based on the target programming language (Gore, column 3 lines 6-35, discloses: “FIG. 1 schematically illustrates one or more distributed or other data-handling media 100 comprising one or more instances of parsers 114, of interpreters 115, of compilers 116, of functions 117, of translators 118, of transpilers (e.g., combining a translator 118 with a compiler 116), of vulnerabilities 119, of services 120, or of other such software 110 or other data items in which one or more technologies may be implemented.” Gore, column 12 lines 36-41, discloses: “Operation 1110 describes readying an environment, such as by retrieving, accessing, or otherwise obtaining a translator 218 or local language specification 230 (e.g., pertaining to an instantiation of one or more environments 292, 392, 1092 described herein) or allocating computing resources for its use.” Gore, column 12 lines 45-48, discloses: “Operation 1130 performs a translation upon that segment from an upstream language into a current local language.” Examiner's notes: column 3 lines 6-35 establishes that Gore's system holds not one transpiler but multiple instances of translators and transpilers, satisfying “a plurality of available transpilers.” Column 12 lines 36-41 establishes the selection: before translating, the system obtains the particular translator that pertains to the environment the code is bound for. Column 12 lines 45-48 establishes what that environment supplies — the current local language into which the segment is then translated. Because the translator retrieved is the one belonging to the environment whose language is the destination of the translation, the retrieval is a selection made on the basis of the target programming language, as claimed.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the teachings of Rattray in view of Smith, by selecting a transpiler from a plurality of available transpilers based on the target programming language as suggested by Gore, because Rattray already emits output in a plurality of different target programming languages from one declarative source and must therefore reach a different language-specific facility for each such target, and maintaining those facilities as a set from which the one matching the target language is retrieved, as Gore does at column 12 lines 36-41, is a predictable and orderly way to extend that capability to further target languages without rewriting the generator itself, thereby providing a systematic mechanism for converting source code from one high-level programming language or version to another as taught by Gore.
With respect to claim 14, the claim recites limitations similar to claim 7 and is rejected for the same reasons set forth for claim 7 above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights