Office Action Predictor
Last updated: April 15, 2026
Application No. 18/288,414

VERSION MANAGEMENT METHOD, NON-TRANSITORY COMPUTER-READABLE MEDIUM STORING VERSION MANAGEMENT PROGRAM, AND VERSION MANAGEMENT SYSTEM

Non-Final OA §103
Filed
Oct 26, 2023
Examiner
SLACHTA, DOUGLAS M
Art Unit
2193
Tech Center
2100 — Computer Architecture & Software
Assignee
Omron Corporation
OA Round
1 (Non-Final)
82%
Grant Probability
Favorable
1-2
OA Rounds
2y 3m
To Grant
99%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allow Rate
279 granted / 340 resolved
+27.1% vs TC avg
Strong +18% interview lift
Without
With
+18.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
20 currently pending
Career history
360
Total Applications
across all art units

Statute-Specific Performance

§101
21.2%
-18.8% vs TC avg
§103
45.6%
+5.6% vs TC avg
§102
8.2%
-31.8% vs TC avg
§112
17.0%
-23.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 340 resolved cases

Office Action

§103
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 . DETAILED ACTION This office action is in response to communication filed 10/26/2023. Claims 1-8 and 11-22 are currently pending and claims 9-10 are cancelled. Claims 1, 11, and 19 are the independent claims. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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-8 and 11-22 are rejected under 35 U.S.C. 103 as being unpatentable over Stump et al. (herein called Stump) (US PG Pub. 2021/0096978 A1) and Ghare et al. (herein called Ghare) (US PG Pub. 2020/0159648 A1). As per claim 1, Stump teaches: a version management method of a program of a control device comprising: generating, from a project of a first version, a first execution file and a first simulation execution file necessary for simulation of the first execution file, and registering the first execution file and the first simulation execution file in an execution data repository (pars. [0003], [0055]-[0056], [0077], [0084]-[0086], system project (project of first version) includes control code of devices/industrial controller/industrial asset/etc. which is translated into controller code/control program file/etc. for execution of specified industrial controller/device/asset/etc. (generate first execution file) and test scripts/scenario/etc. are assembled/created/etc. for system project using automation object of industrial assets/devices/etc. that encode testing/simulation/define simulated test inputs/simulate associated industrial assets/etc. of system project and are executed against system project (generate simulation execution file), which are stored in IDE system/library/storage/etc. (register execution file and simulation execution file in execution data repository).); deploying the first execution file in the control device (pars. [0049], [0054], [0075], [0077], system project/executable files of system project/etc. are deployed/sent/etc. to target devices/target control devices/industrial controller/etc. (control device) for execution); linking the control device to the project of the first version (pars. [0077], [0079], industrial controller/target control devices/etc. to which system project is to be deployed are specified/identified/discovered/etc. (linking/specifying/etc. control device/industrial controller/etc. to the project of the first version/system project/etc.).); and acquiring the first execution file and the first simulation execution file for the simulation of the first execution file (pars. [0085]-[0086], [0101]-[0102], test scripts associated with automation objects (first simulation execution file) are executed by feeding simulated test inputs from test scripts to control code of system project (first execution file) and evaluating responses of the code to the simulated input (simulation of the first execution). As the first execution file and first simulation execution file are used to simulate execution of the execution file using simulated inputs, it is obvious the first execution file and first simulation execution file are acquired for simulation of the first execution file.). Stump does not explicitly state, however Ghare teaches: specifying the project of the first version linked to the control device, based on detection of a failure in the first execution file deployed in the control device (pars. [0053], [0059], [0061], when sensor data obtain from robotic device (control device) indicates a failure/that there is an issue/etc. with application installed on device (first execution filed deployed in control device)/that application on device has crashed during execution/etc. (detection of a failure in the first execution file deployed in the control device), device management service obtains/identifies/etc. earlier version of the application (project from Stump) from data storage and transmits earlier version of application to device for installation and execution/rollback to earlier version. As the management service obtains an earlier version of an application/project and transmits/installs/etc. the earlier version when a failure occurs in execution of a version of the application installed on the device/control device, it is obvious that the project of the first version linked to the control device is specified/identified/obtained/etc. so that an earlier version of the project/application/etc. may be obtained and installed on the device.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add specifying the project of the first version linked to the control device, based on detection of a failure in the first execution file deployed in the control device, as conceptually taught by Ghare, into that of Stump because these modifications allow for a method of determining code/project/version/application having errors/failures/etc. during execution so that versions addressing/fixing/not having/etc. the errors/failures/etc. may be determined and installed on the devices, thereby allowing for problems/errors/failures to be corrected helping to ensure that code/applications/devices/etc. operate/execute correctly/as desired/etc.. As per claim 2, Stump does not explicitly state, however Ghare teaches: wherein the linking the control device to the project of the first version includes linking a device identifier (ID) of the control device to a version ID and a project ID of the project of the first version (pars. [0049]-[0050], [0053], application/project deployed and installed on robotic device may have multiple versions/earlier and latest versions/etc., and user/customer/etc. specifies/selects robotic device/which robotic device to install selected/specified/etc. application which may include submitting a request that includes a name of the robotic device (device identifier) and a unique name of the application (version ID and project ID of the project of the first version). As there are multiple versions of application/project installed on robotic device, and a name of the robotic device and unique name of application is specified in request to install application version to robotic device, it is obvious that a device identifier/name specifying the robot device to which the application is to be installed is linked to a version and project ID/unique application name specifying the version of the application to install on the specified robotic device.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add wherein the linking the control device to the project of the first version includes linking a device identifier (ID) of the control device to a version ID and a project ID of the project of the first version, as conceptually taught by Ghare, into that of Stump because these modifications allow for a method of specifying/tracking/etc. which device is to have which version of a project/code/application installed, thereby increasing user control over the application/code and device and helping to ensure that devices have desired versions of application/code executing/operating on them. As per claim 3, Stump does not explicitly state, however Ghare teaches: further comprising notifying, based on the detection of the failure in the first execution file deployed in the control device, a user terminal of information on the failure and the project of the first version (pars. [0025], robotic management service provides GUI to customer (user) to manage/interact with/etc. robotic devices, customer/user communicates with robotic devices and robotic devices communicate with customer/users through authentication application, and authentication application is used to monitor execution of application on robotic devices to determine whether there are any issues in the execution (detect failure in first execution file deployed in the control device). As the robotic devices communicate with the customer/user through provided GUI and authentication application allows robotic device to communicate with user/customer and is used to monitor for issues/failures during execution of application/file deployed in control device/etc., it is obvious that a user terminal/user/customer/GUI/etc. is notified/communicated to/etc. of information on the failure and the project of the first version based on detecting the failure/issue in the execution file deployed in the control device/robotic device.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add further comprising notifying, based on the detection of the failure in the first execution file deployed in the control device, a user terminal of information on the failure and the project of the first version, as conceptually taught by Ghare, into that of Stump because these modifications allow for users/customers/etc. to be informed/notified/etc. of issues/errors/failures/problems in projects/code/application/etc. executing on devices so they may manage/address/etc. the application and device as they desire, thereby increasing user control over the project/application/code and device while helping to ensure that application/device/etc. operate/execute as desired by users. As per claim 4, Stump does not explicitly state, however Ghare teaches: wherein the first execution file is linked to the device ID (pars. [0049]-[0050], [0053], user/customer/etc. specifies/selects robotic device/which robotic device to install selected/specified/etc. application (first execution file) which may include submitting a request that includes a name of the robotic device (device ID) and a unique name of the application to be installed (version ID and project ID of the project of the first version). As a name of the robotic device/device ID and the unique name of the application version to be installed and executed on the device/first execution file is specified in request to install application version to robotic device, it is obvious that the first execution file/application installed and executed/etc. is linked to the device ID.), the first simulation execution file is linked to the project ID (pars. [0048], [0057], simulation data used to perform simulation of application (simulation execution file from Stump) is stored in data storage, and data/objects/simulation data/simulation execution file/etc. is retrieved from data storage/database/object data storage service/etc. based on requests which include specifier of an identifier of the application (project ID). As the simulation data is stored in data storage and data/simulation ID is retrieved from data storage based on requests that include application identifier/project ID, it is obvious that the simulation execution file is linked to the project ID.), and the acquiring the first execution file and the first simulation execution file for the simulation of the first execution file includes: acquiring the first execution file from an execution data repository, based on the device ID (pars. [0048], [0057], application/first execution file is obtained from data storage and transmitted using provided identifier of device/robotic device/etc. (acquire first execution file/application from execution data repository/data storage based on the device ID/provided identifier of robotic device).); and acquiring the first simulation execution file from an execution data repository, based on the project ID (pars. [0047]-[0048], simulation data used to perform simulation of robotic device (simulation execution file from Stump) is retrieved from storage and provided to perform simulation using the identified application (acquired based on project/application ID).). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the first simulation execution file is linked to the project ID, and the acquiring the first execution file and the first simulation execution file for the simulation of the first execution file includes: acquiring the first execution file from an execution data repository, based on the device ID; and acquiring the first simulation execution file from an execution data repository, based on the project ID, as conceptually taught by Ghare, into that of Stump because these modifications allow for an effective method of obtaining/acquiring/retrieving/etc. files/execution and simulation files/etc. from storage when desired so that they may be used to perform simulation when desired by users, which is desirable as it increases the usability of the files/data by allowing it to be stored and retrieved for use when desired by users thereby making it more desirable to users. As per claim 5, Stump further teaches: wherein the acquiring the first execution file and the first simulation execution file for the simulation of the first execution file includes generating again the first execution file and the first simulation execution file from the project of the first version (pars. [0003], [0055]-[0056], [0077], [0084]-[0086], [0101]-[0102] system project/project of first version includes control code of devices/industrial controller/industrial asset/etc. which is translated into controller code/control program file/etc. for execution of specified industrial controller/device/asset/etc. (generate first execution file) and test scripts/scenario/etc. are assembled/created/etc. for system project using automation object of industrial assets/devices/etc. that encode testing/simulation/define simulated test inputs/simulate associated industrial assets/etc. of system project and are executed against system project (generate simulation execution file), and test scripts associated with automation objects/first simulation execution file are executed by feeding simulated test inputs from test scripts to control code of system project/first execution file and evaluating responses of the code to the simulated input. As the first execution file and first simulation execution file are used to simulate execution of the execution file using simulated inputs, it is obvious the first execution file and first simulation execution file are acquired for simulation of the first execution file, and as the first execution file and first simulation execution file are generated, it is obvious that the generation may be repeated as desired/required when obtaining/acquiring/etc. the first execution file and first simulation execution file, and as such it is obvious that the acquiring the first execution file and the first simulation execution file for the simulation of the first execution file may include repeating the generation of/generating again/etc. the first execution file and the first simulation execution file from the project of the first version.). As per claim 6, Stump does not explicitly state, however Ghare teaches: deploying in the control device, based on occurrence of the failure in the control device, a second execution file generated from a project of a second version older than the project of the first version (pars. [0053], [0059], [0061], when sensor data obtain from robotic device (control device) indicates a failure/that there is an issue/etc. with application installed on device/that application on device has crashed during execution/etc. (based on occurrence of the failure in the control device), device management service obtains/identifies/etc. earlier version of the application/project from data storage and transmits earlier version of application to device for installation and execution/rollback to earlier version (deploy a second execution file generated from a project of a second version older than the project of the first version in control device). As the management service obtains an earlier version/second version older than the project of the first version/etc. of an application/project and transmits/installs/etc. the earlier version when a failure occurs in execution of a version of the application installed on the device/control device, and as Stump teaches that deploying/transmitting project versions/code/application to control devices includes generating execution files/code/etc. from project, it is obvious that a second execution file generated from a project of a second version older than the project of the first version is deployed in the control device based on occurrence of the failure in the control device.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add deploying in the control device, based on occurrence of the failure in the control device, a second execution file generated from a project of a second version older than the project of the first version, as conceptually taught by Ghare, into that of Stump because these modifications allow for a method of determining code/project/version/application having errors/failures/etc. during execution so that versions addressing/fixing/not having/etc. the errors/failures/etc. may be determined and installed on the devices, thereby allowing for problems/errors/failures to be corrected helping to ensure that code/applications/devices/etc. operate/execute correctly/as desired/etc.. As per claim 7, Stump does not explicitly state, however Ghare teaches: performing, based on the detection of the failure in the first execution file deployed in the control device, the simulation of the first execution file by using the first simulation execution file (pars. [0053], when there is an issue/failure/etc. with application/first execution file/etc. executing on robotic device (based on the detection of the failure in the first execution file deployed in the control device) earlier version of the application/execution file/etc. is installed and executed on device/control device while simultaneously performing simulation using the application having the issues/failure/etc. to address identified issues (perform simulation of first execution file). And as Stump teaches that simulation of execution file is performed by using simulation execution file, as seen in the rejection of claim 1, above, it is obvious that simulation of first execution file is performed by using the first simulation execution file.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add performing, based on the detection of the failure in the first execution file deployed in the control device, the simulation of the first execution file by using the first simulation execution file, as conceptually taught by Ghare, into that of Stump because these modifications allow for an effective method of determining and addressing/correcting/etc. issues/failures/errors/etc. is application versions/execution files/etc. thereby helping to correct/fix/address errors/failures/bugs/etc. and ensure that code/files/applications/etc. operate/execute correctly/as desired/etc.. As per claim 8, Stump does not explicitly state, however Ghare teaches: receiving a commit of the project of the first version, based on completion of the simulation of the first execution file (pars. [0059], version of application is updated to address issues impacting performance based on simulations performed using application (based on completion of the simulation of the first execution file/application), and versions of application/a latest version of application/updated version of application/etc. (commit of project of the first version) is maintained/stored/etc. (committed) in data storage (receive commit of project of the first version/updated version of application/latest version of application/etc. based on completion of the simulation of the first execution file/application).). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add receiving a commit of the project of the first version, based on completion of the simulation of the first execution file, as conceptually taught by Ghare, into that of Stump because these modifications allow for projects/applications/code/etc. to be updated/modified/etc. and for updated/modified/newer/latest versions to be simulated/tested/etc. for errors/issues/etc., thereby helping to determine/identify and address/correct/fix errors/performance issues in application/code/etc. which helps ensure the application/code/project operates correctly/as desired/etc.. As per claims 11 and 16-18, they recite systems having similar limitations as the methods of claims 1 and 6-8, respectively, and are therefore rejected for similar reasoning as claim 1 and 6-8, respectively, above. As per claims 19-22, they recite non-transitory computer-readable mediums having similar limitations as the methods of claims 1-4, respectively, and are therefore rejected for similar reasoning as claim 1-4, respectively, above. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS M SLACHTA whose telephone number is (571)270-0653. The examiner can normally be reached Monday-Friday 6:30am-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, Chat Do can be reached at 571-272-3721. 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. /DOUGLAS M SLACHTA/Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Oct 26, 2023
Application Filed
Sep 25, 2025
Non-Final Rejection — §103
Apr 01, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585449
ARTIFICIAL INTELLIGENCE (AI) MODEL DEPENDENCY HANDLING IN HETEROGENEOUS COMPUTING PLATFORMS
2y 5m to grant Granted Mar 24, 2026
Patent 12585463
SELECTIVE TRIGGERING OF CONTINUOUS INTEGRATION, CONTINUOUS DELIVERY (CI/CD) PIPELINES
2y 5m to grant Granted Mar 24, 2026
Patent 12572664
Using Artificial Intelligence (AI) Analysis For Identifying Potential Vulnerabilities Inserted Into Software
2y 5m to grant Granted Mar 10, 2026
Patent 12554558
SEPARATING APPLICATION PROGRAMMING INTERFACES INTO CONTAINERS TO FACILITATE SAFETY ASSURANCE
2y 5m to grant Granted Feb 17, 2026
Patent 12554487
VERSION CONTROL SYSTEM
2y 5m to grant Granted Feb 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
82%
Grant Probability
99%
With Interview (+18.3%)
2y 3m
Median Time to Grant
Low
PTA Risk
Based on 340 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month