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 .
Claims 1-20 have been examined.
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 15-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 15 reciting a “non-transitory computer readable media”, is not limited to tangible storage devices in view of par. 00271, in the instant specification, which suggests that such a medium may be a carrier wave or transmission medium (intangible). Accordingly, claim 15 does not recite tangible manufactures, and are non-statutory subject matter.
As per claims 16-17, these claims are rejected for failing to cure the deficiencies of the above rejected base claim 15.
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, 8, 14, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rajagopalan (US 2025/0156384) in view of Vadaparty (US 12,360,791).
Regarding claim 18, Rajagopalan teaches a processor; a non-transitory computer readable memory storing instructions programmed to cooperate with the processor to perform operations for converting legacy software into modern software; ([0175] “All of the software stored within memory 901 can be stored as a computer-readable instructions, that when executed by one or more processors 902, cause the processors to perform the functionality described”; and [0186] “End-to-End Process Orchestration that takes the application from its legacy state through the transformation process to a modern platform without requiring extensive manual intervention”); first identifying content types within the legacy software and the supporting content; ([0032] “At step 303 the legacy application code is analyzed to determine one or more complexity values. This step generates an inventory of the database and documents all tables, columns, indexes, constraints, and relationships in the SQL database”); first determining one or more software categories for the legacy software and the supporting content; ([0085] “This step can include complexity benchmarking which categorizes stored procedures, functions, views, packages, triggers, and other database objects into small, medium, or high complexity based on criteria such as lines of code, the number of joins, and/or the complexity of their logic. This classification can then be utilized to prioritize optimization efforts”); second identifying actions to be taken for the determined software categories; ([00118] “The step of determining destination database values can additionally include determining a methodology that supports various migration strategies, such as rewriting an application or maintaining a hybrid setup for a transition period. This can include designing a migration methodology by guiding the user through predefined prompts and providing recommendations based on the current system architecture, data dependencies, and performance requirements. The chatbot suggests strategies, identifies risks, and offers best practices tailored to the application’s characteristics"); first selecting a plurality of foundation models, based on the identified content types and the identified actions, to support the conversion;(EN: Examiner’s interpretation that foundation models include LLMs to support the conversion per [0070-0072] of claimed invention “foundation models may include Large Language Models (LLMs)… any Machine Learning (ML) models, or Artificial Intelligence (AI) models, or any other similar models”.) (Rajagopalan [0017] “The exact nature of a transformation process and a desired output are also understood from known techniques. Based on this knowledge, LLMs are trained with an iterative process, which may be referred to as “Prompt Engineering,” by designing the correct stages of transformation and iteratively working through the correct prompt design to achieve the desired output. But because typical transformations rely on direct conversions, and direct conversion of legacy code to new code does not work, the present system is built with clear intermediation, which uses the LLM to understand the code and generate functional documentation”); first generating a sequence of steps for each of the actions to convert the legacy software into the modern software, the sequence of steps including foundation model steps and non-foundation model steps; ([0119] “The steps of a migration methodology can include…: [00120] Data and Schema Analysis...[00121] Schema Mapping... [00122] Data Transformation ... [00123]Data Transfer Planning ... [00124] Testing... [00125] Deployment and Validation ... [00126] Exemplary, non-limiting migration strategies include: [00127] One-Time Migration ... [00128] Incremental Migration”); (EN: Examiner’s interpretation per [00103] of the claimed invention that foundation model steps – also referred as prompt steps – may involve the foundation model and the associated prompts whereas non-foundation model steps may be referred to as non-prompt steps in which the foundation models are not considered. Rajogapalan teaches sequence of steps for that can be interpreted as a combination of non-foundation model steps [0043] and foundation model steps involving LLMs [0045]) (Rajagopalan [0043] “At step 203 …This step can parse and analyze these database objects to determine their purpose, dependencies, and the tables they interact with. This step can additionally include extracting the logic from stored procedures and functions to determine their functionality.”) ([0045] “Step 203 can include the LLM receiving or retrieving SQL DDL scripts for stored procedures, functions, views, and other objects. The LLM then extracts key information about each object, such as its purpose, dependencies, and interactions with tables. Where a package contains multiple SQL artifacts … a custom parsing step can be performed to isolate individual SQL components within the package, such as stored procedures, functions, views, and triggers. Each extracted artifact is then individually fed to the LLM, which analyzes each artifact to extract detailed insights”); ([0094] “The query and the relevant information retrieved from the data store is then fed to an LLM, and the LLM constructs the output and provides it to the user.”) (EN: Examiner interprets in [0094] as a non-foundation model step the retrieval from the data store and the LLM constructing the output and providing it to the user as a foundation model step); second determining if any necessary software to execute the steps is missing; second generating, in response to a positive result of the second determining, replacement software for the missing software; ([00141] “Step 506 can further include generating net new code, which includes code modules or functions that did not exist in the legacy code and are created to support new requirements or technologies in the generated migration code”); and executing the sequence of steps for each of the actions to generate the modern software; ([00167] “At step 702 the validated migration code is executed in accordance with the provisioned infrastructure”). Rajagopalan does not explicitly teach receiving the legacy software and any supporting content for conversion.
However, Vadaparty teaches receiving the legacy software and any supporting content for conversion (Vadaparty, column 22, lines 59-65: “A system according to various embodiments can comprise … a user device … for uploading to the LLM a file with source code, written in a first programming language, of the legacy software program”).
It would have been obvious to one having ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system disclosed by Rajagopalan to include receiving the legacy software and any supporting content for conversion using the teaching of Vadaparty. The modification would be obvious because one of ordinary skill in the art would be motivated to update legacy systems used by enterprise systems (Vadaparty, column 1, line 55 to column 2).
Per Claim 1:
This is a method version of the claimed system discussed above (claim 18, respectively), wherein all claim limitations also have been addressed and/or covered in cited areas as set forth above. Thus, accordingly, this claim is also obvious.
Regarding claim 2, the rejection of claim 1 is incorporated, Rajagopalan further teaches “wherein the content types include any of software code, images, non-software text, and/or audio”; ([0015] “legacy database migration”, [0032] “This step generates an inventory of the database and documents all tables, columns, indexes, constraints, and relationships in the SQL database. … Corresponding metadata can be organized and stored in a document database to enable indexing and retrieval for analysis.”, [0034] “Each record in one table links to one in another (e.g., Employee and EmployeeDetails. [0038] … A record links to multiple table types (e.g., comments on posts, images, or videos”)).
Regarding claim 3, the rejection of claim 1 is incorporated, and Rajagopalan further teaches wherein the software categories include any of legacy language code, Infrastructure as Code, Dev-Ops as code, user interface code, and/or images ([0059] “At step 205, one or more of database logs of the legacy database, code patterns of legacy application code, and configuration files are analyzed to identify one or more non-functional requirements.”, [0085] “At step 303 the legacy application code is analyzed to determine one or more complexity values. This step can include complexity benchmarking which categorizes stored procedures, functions, views, packages, triggers, and other database objects “, [0170] “the legacy database environment can include a legacy database and legacy application code that interfaces with the legacy database. The legacy database can include structures corresponding to a database footprint, database artifacts, and database logs. The legacy application code can include a data access layer, repository layer, data transfer objects, a controller, and an application log”).
Regarding claim 8, the rejection of claim 1 is incorporated, and Rajagopalan further teaches determining, based on the identified actions, corresponding quality metrics to measure performance of the foundation model steps; and the first generating the sequence of steps comprises selecting steps that satisfy the corresponding metrics (par. 0017 and 0028).
Regarding claim 14, the rejection of claim 1 is incorporated, and Rajagopalan further teaches generating graphs for visualizing the results of execution of the sequence of steps for each of the actions; and creating a collaborative platform for accessing the results of execution of the sequence of steps (par. 0168).
Per Claim 15:
This is a media version of the claimed system discussed above (claim 18, respectively), wherein all claim limitations also have been addressed and/or covered in cited areas as set forth above. Thus, accordingly, this claim is also obvious.
Claims 4, 6, 16, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rajagopalan (US 2025/0156384), in view of Vadaparty (US 12,360,791), and further in view of Abdulhayoglu (US 2024/0028315).
Regarding claim 19, the rejection of claim 18 is incorporated, Rajogapalan further teaches the operations further comprising: third determining, based on a size of the legacy software, whether the legacy software requires chunking before executing; ([0085] At step 303 the legacy application code is analyzed to determine one or more complexity values. This step can include complexity benchmarking which categorizes stored procedures, functions, views, packages, triggers, and other database objects into small, medium, or high complexity based on criteria such as lines of code, the number of joins, and/or the complexity of their logic. This classification can then be utilized to prioritize optimization efforts”); second selecting, in response to a positive result of the third determining, at least one chunking methodology appropriate for the legacy software; and separating at least a portion of the legacy software into chunks per the selected at least one chunking methodology; ([00187] “Content-aware and specialized chunking algorithms implemented for different types of data including database code, services code, UI code and logs”). Rajagopalan does not explicitly teach wherein the executing the sequence of steps comprises executing the sequence of steps on the chunks.
However, Abdulhayoglu teaches wherein the executing the sequence of steps comprises executing the sequence of steps on the chunks ([0005] “The present invention overcomes the prior problems by taking a piece or section of generated code and spliting up the piece of generated code into multiple pieces so that each piece of code runs independent of each other piece of code, but also connects the pieces of code through communication protocols, so the functionally (from the user's perspective) is that the code runs as if it were a single piece. These code slices are each capable of distribution to various devices that can run each piece it receives.)” ([0011] “The present invention has several advantages over prior methods. The present invention achieves distributed load across multiple devices and also redundancy—once the execution path has been defined, each device can make decisions on how to optimize executing the next part of the code. A second effect of the present invention is that execution has built in redundancy—if one of the devices is not available for any reason, the device's work load is taken up by one or more other device(s). A third benefit is that complex codes, which can consume a lot of resources to run can be split in smaller chunks and distributed to multiple devices to run it—this way each device only has to handle a lower overall load, permitting each device to be involved in running more code.”)
It would have been obvious to one having ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system disclosed by Rajagopalan to include executing of the sequence of steps on the chunks using the teaching of Abdulhayoglu. The modification would be obvious because one of ordinary skill in the art would be motivated for improved performance and responsiveness, and to avoid overload of the device running code that is complex, or if there is a large number or volume of codes. (Abdulhayoglu [0004]).
Regarding claim 20, the rejection of claim 19 is incorporated, Rajagopalan further teaches “wherein the generating a sequence of steps further comprises: obtaining from a global template repository, an existing series of steps appropriate for the conversion”; ([0130] “the Co-Pilot can create migration code through a combination of pre-built artifacts from a stored repository … Pre-built artifacts are ready-made components that accelerate code generation, such as a repository template that standardizes CRUD operations on a No-SQL database, a service template for encapsulating business logic, and validation snippets for verifying input data against constraints. Pre-built artifacts can be categorized into the following: [0131] Templates: Pseudo-code structures for controllers, services, and repositories. … Controller templates can include templates for API endpoints. … Services templates can include business logic encapsulation. Repository templates can include data access layer templates, such as using JPA or MongoDB. Models/Entities templates can include basic entity classes with fields, relationships, and annotations. [0132] Business Logic Snippets: Code blocks for common logic patterns such as CRUD operations, pagination, and validation”); and/or submitting the software categories and at least some of the received supporting content to a template generation model and receiving in response at least some of the steps for each of the actions from the template generation model including the foundation model steps and the non- foundation model steps; ([0029] “…step 103 migration code for migrating the legacy database to the destination database is generated based at least in part on one or more code generation templates, entity definitions, legacy code analysis, schema mapping information, one or more user preferences, and one or more code generation procedures configured to create one or more files and one or more directories based at least in part on the one or more code generation templates. This step can include receiving the schema and entity information for the new system, selecting a controller template for managing CRUD operations for a particular entity (e.g., “Product”), based on the schema, filling in specific fields, mappings, and any validation rules, generating customized queries or operations based on parameters like entity relationships, data constraints, and access patterns are considered, and saving the generated code, completing any additional setup (e.g., adding route mappings), and providing documentation.) ([171] “The migration platform further includes a large language model used for legacy system analysis and code generation”).( [182] ”The present solution utilizes a multi-faceted approach to application modernization with several components, such as:” [0183] “Large Language Models (LLMs) to parse and understand the legacy code and database artifacts”.) (EN: Examiner’s interpretation of the Large Language Models (LLM) as the recited template generation model”).
Per Claims 4 & 6:
These are method versions of the claimed system discussed above (claims 19-20, respectively), wherein all claim limitations also have been addressed and/or covered in cited areas as set forth above. Thus, accordingly, these claims are also obvious.
Per Claims 16-17:
These are media versions of the claimed system discussed above (claims 19-20, respectively), wherein all claim limitations also have been addressed and/or covered in cited areas as set forth above. Thus, accordingly, these claims are also obvious.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Rajagopalan (US 2025/0156384), in view of Vadaparty (US 12,360,791), and further in view of Dhruv (U.S. 8,583,818).
Regarding claim 5, the rejection of claim 1 is incorporated, and further, Rajagopalan does not explicitly teach wherein the second selecting at least one chunking methodology comprises selecting: logical chunking for object oriented programming; token based chunking for non-object oriented programming; file size based chunking for audio files; duration length based chunking for video files; and image-token based chunking for image files.
However, Dhruv teaches wherein the second selecting at least one chunking methodology comprises selecting: logical chunking for object oriented programming; token based chunking for non-object oriented programming; file size based chunking for audio files; duration length based chunking for video files; and image-token based chunking for image files (e.g. see abstract).
It would have been obvious to one having ordinary skill in the computer art before the effective filing date of the claimed invention to modify the method disclosed by Rajagopalan to include wherein the second selecting at least one chunking methodology comprises selecting: logical chunking for object oriented programming; token based chunking for non-object oriented programming; file size based chunking for audio files; duration length based chunking for video files; and image-token based chunking for image files using the teaching of Dhruv. The modification would be obvious because one of ordinary skill in the art would be motivated to improve video playback effects for end users (Dhruv, column 1, lines 31-33).
Allowable Subject Matter
Claims 6-7 and 9-13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bachelor (US 2012/0259909) teaches a method for migrating legacy applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QAMRUN NAHAR whose telephone number is (571)272-3730. The examiner can normally be reached Monday - Friday 8-4pm.
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.
/QAMRUN NAHAR/Primary Examiner, Art Unit 2199