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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references 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.
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.
Claims 1-3, 5, 7, 9-16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US-20180314505-A1) in view of Parsad et al. (US20250199787A1)
Regarding Claim 1, Wang teaches A computer-implemented method for code translation, comprising: translating original data structures from original code in a first programming language to translated data structures in a second programming language using a language model (Wang, [0073] "FIG. 3 is an exemplary embodiment of an ALC to Java translation system 3011 In various embodiments, Java translation system 300 includes a Data Extract Tool that performs functions to build the data model automatically from ALC data elements. This tool can scan the ALC source codes and extract out the data definitions to build the data model automatically. Because the physical layer of the data model in the translated TRL codes have similar attributes to ALC codes, a unique validation approach has been developed that can effectively validate the translated TRL code fragments at any granular level. In this validation approach the memory of the ALC code at runtime, (e.g., on IBM mainframe), is dumped at any selected point and can be compared to that of the translated TRL code at runtime, (e.g., on a Linux server). This approach allows for any selected fragment of the translated TRL codes (e.g., a module or a subroutine) to be validated against the ALC version of the same code." [0091-0093] "FIG. 8 is a schematic illustrating an exemplary Data Extraction Tool used to generate JOM data structures. The data extraction tool generates Java Object Model (JOM) data structures. As illustrated in FIG. 8, an ALC listing is scanned line by line to capture all ALC constructs or data structures into system tables. ALC constructs are subsequently categorized, organized, and stored into extraction expected data structures. These data structures are the predesigned Java classes which are generic enough to abstract ALC data, including type and value, instructions, and flow control variables into object oriented data structures. These data structures subsequently fed into TRL engine or TRL to Java tool to execute the translated TRL or Java programs, and produce the expected outputs the same as the original ALC program does. The next step is to translate the ALC data elements into object oriented Java data structures. The extraction processes the system table obtained from the scanning process, collects all data declarations such as CSECT, DSECT and gate variables for flow control including self-modified variables, and then transforms them into Java objects.")
dividing the original code into a set of functions, each of the set being associated with any corresponding dependencies from the data structures (Wang, [0125-0126] "In various embodiments, a Sub Finder detects subroutines based on analysis on CFG islands and the user-provided configurations. The Sub Finder detects dynamic subs based on BAS/BAL calls which identify the entrance nodes of the subs. Once the Sub Finder has fully executed its functions, the ALC program is divided into multiple subs. Each sub has its own set of member nodes as a sub CFG." [0117-0118] "In the exemplary embodiment shown, the CFG is a set of nodes which are connected according to the program's execution flow. Starting from any node, all nodes reachable from the starting node form a sub CFG called island. An island does not connect to any other nodes because all nodes reachable following the CFG links are already included in the island. Exit from the island can only be through nodes of dynamic branch instructions (BR, BxR, etc.). CFG islands may be treated as subprograms." Also see [0127-0132])
translating each of the set of functions into translated functions in the second programming language, along with the corresponding dependencies (Wang, [0093] "The next step is to translate the ALC data elements into object oriented Java data structures. The extraction processes the system table obtained from the scanning process, collects all data declarations such as CSECT, DSECT and gate variables for flow control including self-modified variables, and then transforms them into Java objects.")
correcting an error in the translated functions assuming correctness of the translated data structures (Wang, [0069] "For the purpose of promoting an understanding of the present invention, references are made in the text to exemplary embodiments of System of Method Error Handling for Translation of Assembler Language to Java, only some of which are described herein. It should be understood that no limitations on the scope of the invention are intended by describing these exemplary embodiments. One of ordinary skill in the art will readily appreciate that alternate but functionally equivalent functions, steps, logical conventions or exemplary code coding may be used. The inclusion of additional steps or elements may be deemed readily apparent and obvious to one of ordinary skill in the art. Specific elements disclosed herein are not to be interpreted as limiting, but rather as a basis for the claims and as a representative basis for teaching one of ordinary skill in the art to employ the present invention." and [0014] "One Model includes a physical Layer which simulates the ALC physical memory structures. A two-layer data model performs Analyzer functions on ALC program files to detect code. ALC to TRL Translator Tool generates TRL files, detects translation errors and updates itself until no errors are detected." whereas [0091-0093] shows the data structure being the base of the translation)
However, Wang is not relied upon for:
using the language model
Parsad teaches using the language model (Parsad, [0080-0081] "In various embodiments, in block 508, nodes can be derived from the static analysis entity 506. These nodes 508 can represent the essential elements of the program's control flow and data structures, broken down into granular components that can be individually analyzed and translated. In block 510, metadata can be utilized in conjunction with the nodes, providing additional information about each node, including, for example, data types, scope, and variable dependencies. This metadata can be utilized for ensuring that the translated code preserves the functionality and logic of the original code. In block 512, a program skeleton can be built using the Nodes 508 and Metadata 510 to construct a skeletal version of the target program. This skeleton can form the blueprint for the translated code, and can include placeholders for logic and data that can be filled in by the LLM. The Target Language Skeleton in block 514 can represent the structured format of the translated code as it begins to take shape. Here, the foundational elements of the target program can be laid out, ready to be populated with actual code generated by the LLM. In block 516, Translation Context Placeholders can be strategically positioned within the Target Language Skeleton 514. These placeholders can be filled with contextually relevant code snippets, ensuring that the translation is not only syntactically correct but also functionally equivalent to the original code, in accordance with aspects of the present invention.")
Wang and Parsad are analogous art because they are from the same field of endeavor in translating programming languages. Parsad teaches a known method of using LLMs to perform the translation from one language to another. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Wang and Parsad to utilize Parsad’s known technique into the environment and processes of Wang which teaches using data structures as a basis for translating from one language into another expected results. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Regarding Claim 2, Wang in view of Parsad teaches the method of claim 1. Parsad teaches wherein a number of tokens of each function of the set of functions and its corresponding dependencies is below a prompt token limit for the language model (Parsad, [0028-0029] "Pre-trained Large Language Models (LLMs) brought advancements with their ability to perform in-context learning, adapting to new tasks during inference by conditioning on a few examples. This method has been successful in natural language processing tasks. However, its application to code translation is complicated by the difficulty in specifying context for translation between programming languages, the limited token size processing capacity of LLMs, and the tendency of LLMs to generate hallucinatory or unfaithful output. In view of these challenges, the present invention improves upon conventional systems and methods by integrating neural network models with advanced contextual data processing strategies. In some embodiments, the invention employs an adaptive system that enhances accuracy and efficiency in code translation by using context-aware neural networks and optimization techniques. This system and method can maintain the integrity of the original code's logic and semantics while optimizing the translated code for the target environment's specific operational conditions and performance needs, in accordance with aspects of the present invention." and [0003])
Regarding Claim 3, Wang in view of Parsad teaches the method of claim 1, wherein correcting the error includes correcting a variable in the translated functions that is mapped to an incorrect data element as compared to the original code (Wang, [0147-0154] teaches various validation methods to correct errors including those that are wrongly mapped)
Regarding Claim 5, Wang in view of Parsad teaches the method of claim 1. Parsad teaches wherein correcting the error includes filling an empty class in the translated functions (Parsad, [0081] "In block 512, a program skeleton can be built using the Nodes 508 and Metadata 510 to construct a skeletal version of the target program. This skeleton can form the blueprint for the translated code, and can include placeholders for logic and data that can be filled in by the LLM. The Target Language Skeleton in block 514 can represent the structured format of the translated code as it begins to take shape. Here, the foundational elements of the target program can be laid out, ready to be populated with actual code generated by the LLM. In block 516, Translation Context Placeholders can be strategically positioned within the Target Language Skeleton 514. These placeholders can be filled with contextually relevant code snippets, ensuring that the translation is not only syntactically correct but also functionally equivalent to the original code, in accordance with aspects of the present invention.")
Regarding Claim 7, Wang in view of Parsad teaches the method of claim 1, further comprising validating the translated data structures according to a rule before translating each of the set of functions (Wang, [0145-0146] "FIG. 30 illustrates an exemplary verification method for translated TRL code. The verification method illustrated in FIG. 30 provides a mechanism to compare legacy systems to modernized systems and validate translation at any desired level of granularity (inputs/outputs, CSECTS, sub-routines, chunks, and individual lines of code). For translated code which retain processing of sequential files, recreation of those legacy file formats allows direct comparisons." Also see [0147-0154] for the various validation methods.)
Regarding Claim 9, Wang in view of Parsad teaches the method of claim 7, further comprising correcting an error in the translated data structures based on the rule (Wang, [0113] "The translation is an iterative process: the user runs the Scan multiple times and resolve issues incrementally. When the user runs the Scan the first time, no scanner rules are configured because there are no issues to resolve. The Scan detects and reports issues. The user then configures the scanner rules to resolve the issues and run the Scan again. The Scan applies the rules and tries to detect and report remaining issues. This process is repeated until all issues are resolved.")
Regarding Claim 10, Wang in view of Parsad teaches the method of claim 1. Parsad teaches wherein translating each of the set of functions includes using translated version of the corresponding dependencies as context for the language model (Parsad, [0081] and [0091] Fig. 6, Step 616.)
Regarding Claim 11, Wang in view of Parsad teaches the method of claim 1. Parsad teaches further comprising identifying the corresponding dependencies using a query to the language model (Parsad, [0063], Also see Thomas [0024-0025])
Regarding Claim 12, Wang teaches A computer program product, comprising: one or more computer-readable storage media; and program instructions stored on the one or more storage media to perform operations comprising ([0011])
The remaining limitations are similar to claim 1 and are rejected under the same rationale.
Regarding Claim 13, A computer system, comprising: a processor set; one or more computer-readable storage media; and program instructions stored on the one or more storage media to cause the processor set to perform operations comprising ([0011])
Claims 14-16, 18 and 20 recite limitations similar to claims 7, 2, 3, 10 and 5 respectively and are rejected under the same rationale.
Claims 4, 6, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US-20180314505-A1) in view of Parsad et al. (US-20250199787-A1) and further in view of Thomas (US-20240386058-A1)
Regarding Claim 4, Wang in view of Parsad teaches the method of claim 1. Thomas teaches wherein correcting the error includes correcting spelling of a variable in the translated functions based on a similarity to a data element of the translated data structures (Thomas, [0021-0022] "In some scenarios, the prompt generated by the application includes tasks or rules, contextual information associated with the application environment, e.g., spreadsheet environment, and the user's natural language input. The rules may direct the LLM to configure its output in a parse-able format, such as a JSON object or in semantic tags. From the parse-able output received from the LLM, the application extracts the information corresponding to the suggested modification and creates executable commands or source code for implementing the modification in the spreadsheet. The LLM may also be instructed, in the prompt, to generate its output as source code which can be executed without further processing, such as Office JavaScript API source code. In an implementation, the source code generated or translated from the reply (e.g., from a JSON object in the reply) is in the same language (e.g., JavaScript) or uses the same syntax as a command which would be executed if the user had manually changed the property in a chart menu or task pane in the application environment. Thus, the user can implement a modification to a chart via a natural language input which would be equivalent to the user manually changing a chart property in a task pane in the user interface or to the user navigating through a menu system of the application environment to find the chart property and change it. Other rules provided by the prompt may instruct the LLM to constrain its reply to the chart properties of the particular application, such as those for Microsoft Excel® charts. The rules may also direct the LLM to be aware of synonyms to chart properties (e.g., defined terms of other applications) and misspellings of chart properties in the user input (or even a misspelling of a synonym), for example, equating a “foreign” term in the input to a defined property of the chart." [0067] "For an ambiguous or underspecified input, the prompt template includes contextual information which LLM 330 may use to generate a reply. Here, “it” in the user input is unspecified, but because the prompt includes the immediately preceding exchange (“User_Msg (1)” and “Reply (1)”), LLM 330 generates a reply based on inferring that “it” refers to the element of chart 503 that was most recently modified (i.e., the chart title). In addition, as the rules task LLM 330 with taking into consideration that the user input may include misspellings, this allows LLM 330 to generate a reply by assuming that the user meant to enter “bold” rather than “bodl.” In some scenarios, LLM 330 may identify multiple properties and values as being responsive to the user input. The prompt may include a rule for LLM 330 to determine the single most likely property and value for inclusion in its output." also see [0029])
Wang, Parsad and Thomas are analogous art because they are from the same field of endeavor in translating programming languages and data structures. Thomas teaches a known method of correcting names of data parameters based on possible misspellings and the context of data dependencies. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Wang, Parsad and Thomas to utilize Thomas known technique into the environment and processes of Wang which teaches using data structures as a basis for translating from one language into another expected results. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Regarding Claim 6, Wang in view of Parsad teaches the method of claim 1. Thomas teaches wherein correcting the error includes correcting a chain of objects in the translated functions (Thomas, [0024-0025] "Because the natural language input provided by a user is freeform and unconstrained, in various implementations, the LLM is tasked by the prompt to classify the input as a search, a command, feedback, a search for help, a request for a recommendation, ambiguous, requiring clarification, and so on. According to a prompt rule, if the LLM classifies the input as a command, the LLM then determines which chart properties are implicated and new values for the properties. If the user asks, “what's the right chart for my data,” the LLM may classify the input as a search for help or a request for a recommendation and return a reply which indicates the classification along with a suggestion for accommodating the user's request, such as a help article of the application or a recommendation to use a chart design engine of the application or a fine-tuned AI model of the application. In some scenarios, the LLM may reply with a recommended chart type based on contextual data in the prompt that includes at least a portion of the spreadsheet data. In an implementation, the application includes in the prompt a representation of the chart to which the user input refers. The format of the representation is a data structure which includes chart design and format properties which define the chart. The chart properties may be organized in a hierarchical fashion, such as a property tree. For example, the chart title may be a property which includes multiple categories, such as the font, location, visibility, text box formatting, and so on. The font of the chart title may include multiple categories such as the font name, size, style, word art effects (e.g., shadow, reflection, etc.), and so on. The data structure which defines a chart may be a JSON data object including property identifiers, values, descriptions, names, and so on.")
For motivation to combine please see claim 4.
Claims 17 and 19 recite limitations similar to claims 4 and 6 respectively and are rejected under the same rationale.
Claims 8 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US-20180314505-A1) in view of Parsad et al. (US20250199787A1) and further in view of Long et al. (The CERT ® Oracle ® Secure Coding Standard for Java)
Regarding Claim 8, Wang in view of Parsad teaches the method of claim 7. Long teaches wherein the rule is selected from the group consisting of a rule prohibiting inner classes and a rule prohibiting static variables (Pg. 197, “Do not use public static nonfinal variables: Client code can trivially access public static fields. Neither reads nor writes to such variables are checked by a security manager. Furthermore, new values cannot be validated programmatically before they are stored in these fields. In the presence of multiple threads, nonfinal public static fields can be modified in inconsistent ways. See rule TSM01-J for an example. Improper use of public static fields can also result in type-safety issues. For example, untrusted code can supply an unexpected subtype with malicious methods when the variable is defined to be of a more general type, such as java.lang.Object [ Gong 2003 ]. As a result, classes must not contain nonfinal public static fields.”)
Wang, Parsad and Long are analogous art because they are from the same field of endeavor in programming languages and data structures. Long teaches a known method of correcting coding practices to avoid creating security holes and bugs. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Wang, Parsad and Long to utilize Long’s known technique into the environment and processes of Wang which teaches using data structures as a basis for translating from one language into another expected results. Note MPEP 2143- (D) Applying a known technique to a known device (method, or product) ready for improvement to yield predictable results.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bahrami et al. (US-20230106226-A1): discloses code enrichment for training language models for programming.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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 on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/DUY KHUONG T NGUYEN/Primary Examiner, Art Unit 2199
Prosecution Insights