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
1. This action is responsive to the communication filed on 4/06/2026. Claims 1-3 and 5-10 have been amended. Claims 11-20 have been added. Claims 1-20 are pending.
2. Applicants' arguments filed 4/06/2026 have been fully considered but they are not deemed to be persuasive. Rejections and/or objections not reiterated from previous office actions are hereby withdrawn. The following rejections and/or objections are either reiterated or newly applied. They constitute the complete set presently being applied to the instant application.
Claim Rejections - 35 USC § 103
3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
4. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
5. 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.
6. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
7. Claims 1-2, 10, 12, 15-17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG in view of OSAKI et al (US 20210272012 A1 hereinafter, “OSAKI”).
8. With respect to claim 1
ZHANG discloses
a file management system that manages a file system in which a user interface that is operated by an application of a control system is constituted, an application environment in which files operated through the user interface are managed is constituted, and a middle layer in which some of the files used in the application environment are managed for each version of the control system is constituted, the file management system comprising:
a processor configured to:
manage an application image that is a set of the files used in the application (ZHANG [0003] – [0013], [0062] e.g. compatible; The associated collaborative document may be any type of image file that is compatible with a third-party application image viewer; [0013] Some implementations may include a method to receive, by a client device, a request for a file stored within the content management platform in a third-party application format. The client device May present a rendered graphical image of the file within a preview user interface);
manage a middle image that is a set of some of the files managed in the middle layer for each version of the control system (ZHANG [0003], [0010] – [0013], [0028] – [0029], [0032] - [0034], [0045], [0070] – [0076], [0081] – [0096] e.g. version; [0010] In some implementations, generation of a new version of the file that includes content associated with the portion of the file may include the content management platform retrieving a plurality of bytes from the file that correspond to the portion corresponding to the content. The content management platform may then generate one or more new bytes representing the content associated with the portion wherein the one or more new bytes are formatted based upon the third-party application format. The content management platform may generate the new version of the file that includes the plurality of bytes from the file and the one or more new bytes that represent the content associated with the portion corresponding to the received content. [0011] In some implementations, the content management platform may receive a request to store a second version of the file, where the second version of the file contains updated content (e.g. new/updated comments). The content management platform may then extract the new content from the second version of the file and merge the new content with existing content from the currently stored version of the file. The content management platform may then store the second version of the file and the merged content within the content management platform.); and
perform compatibility (ZHANG [0027], [0029], [0032], [0044], [0062], [0071] – [0072], [0081], [0083] e.g. compatible; [0062] The associated collaborative document may be any type of image file that is compatible with a third-party application image viewer) processing for using the middle image selected in the application environment, and place the middle image subjected to the compatibility processing in the application environment to make the middle image usable in the user interface (ZHANG [0013], [0024] – [0026], [0062] e.g. environment; user interface; [0062] The associated collaborative document may be any type of image file that is compatible with a third-party application image viewer; [0013] Some implementations may include a method to receive, by a client device, a request for a file stored within the content management platform in a third-party application format. The client device May present a rendered graphical image of the file within a preview user interface; [0026] The collaborative document may be accessible by collaborators via the cloud-based content management platform hosted by one or more servers in the cloud-based environment. Each collaborator may view the collaborative document at a user's client device within a preview user interface provided by the content management platform or using a third-party application compatible with the file format of the collaborative document. For example, a user may preview the collaborative document through a web browser on their client device using a website associated with the cloud-based content management platform or in a UI of a third-party application installed on the client device.).
Although ZHANG substantially teaches the claimed invention, ZHANG does not explicitly indicate
in a hierarchical structure with multiple version layers;
search the hierarchical structure from an uppermost-level layer to a lowermost-level layer to select the middle image.
OSAKI teaches the limitations by stating
manage a middle image that is a set of some of the files managed in the middle layer for each version of the control system in a hierarchical structure with multiple version layers;
search the hierarchical structure from an uppermost-level layer to a lowermost-level layer to select the middle image (OSAKI [0018], [0026] e.g. [0018] The searching function 100 retrieves container version information 101. The container version information includes the version identifier (ID) of the containers deployed on the corresponding storage systems and servers 120. The searching function 100 searches for the version ID in the container version tree 102. In an example implementation, container version tree 102 can be a Git system, container image versioning system like docker engine or a DockerHub system, or otherwise in accordance with the desired implementation. …. [0026] FIG. 3 illustrates an example use case of the searching function, in accordance with an example implementation. All container images are managed internally by version number and version tree as shown at 102. The ML searching function 300 can also go up and down the version tree 102 gradually as shown at 301 and 302. When the distance between versions is short (e.g., one hop away), the internal operating system (OS) settings and application settings are similar, so the sudden 10 load is similar. Through this concept, the number of 10 load prediction models can be reduced to about 1/100 in comparison to the related art. After traversal of the version tree 102, an example search result could be that there is no ML model that corresponds to the version number of the container, but there is a model that is close based on the distance of the version tree that is applicable as illustrated at 310 [as
manage a middle image that is a set of some of the files managed in the middle layer for each version of the control system in a hierarchical structure with multiple version layers (e.g. version tree);
search (e.g. search) the hierarchical structure (e.g. version tree) from an uppermost-level layer to a lowermost-level layer (e.g. up to down the version tree) to select the middle image (e.g. image versioning)]).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of ZHANG and OSAKI, to predict IO load and prevent application performance failure (OSAKI [0004]).
9. With respect to claim 2,
ZHANG discloses
wherein the processor is further configured to determine whether compatibility processing is necessary for the middle image of the version selected (ZHANG [0003], [0010] – [0013], [0028] – [0029], [0032] - [0034], [0045], [0070] – [0076], [0081] – [0096] e.g. version; [0010] In some implementations, generation of a new version of the file that includes content associated with the portion of the file may include the content management platform retrieving a plurality of bytes from the file that correspond to the portion corresponding to the content. The content management platform may then generate one or more new bytes representing the content associated with the portion wherein the one or more new bytes are formatted based upon the third-party application format. The content management platform may generate the new version of the file that includes the plurality of bytes from the file and the one or more new bytes that represent the content associated with the portion corresponding to the received content. [0011] In some implementations, the content management platform may receive a request to store a second version of the file, where the second version of the file contains updated content (e.g. new/updated comments). The content management platform may then extract the new content from the second version of the file and merge the new content with existing content from the currently stored version of the file. The content management platform may then store the second version of the file and the merged content within the content management platform.), performs the compatibility processing on the middle image for which the compatibility processing is determined to be necessary, and use the middle image subjected to the compatibility processing (ZHANG [0027], [0029], [0032], [0044], [0062], [0071] – [0072], [0081], [0083] e.g. compatible; [0062] The associated collaborative document may be any type of image file that is compatible with a third-party application image viewer).
9. With respect to claim 12,
ZHANG discloses wherein the processor is further configured to merge files (ZHANG [0011], [0029], [0032] e.g. merge) existing in an upper layer and a lower layer without overlapping and display the merged files through the user interface (ZHANG [0013], [0026] e.g. user interface) in a merge layer.
10. With respect to claim 15,
ZHANG discloses wherein the processor is further configured to confirm an activation mode of the control system with reference to an activation mode management table, wherein the activation mode includes an image update mode (ZHANG [0031], [0045], [0065], [0067] – [0068], [0086], [0090], [0094] – [0095] e.g. update) and a normal operation mode.
11. With respect to claim 16,
OSAKI discloses wherein the processor is further configured to search for an execution file having a same name as an execution file executed when the middle image is activated, wherein the searching is performed from the uppermost-level layer to the lowermost-level layer (OSAKI [0018], [0026]).
ZHANG discloses wherein the processor is further configured to search for an execution file having a same name as an execution file executed when the middle image is activated, and load the execution file subjected to the compatibility (ZHANG [0003] – [0013], [0062] e.g. compatible) processing into a merge layer (ZHANG [0011], [0029], [0032] e.g. merge) in which the user interface is constituted.
12. With respect to claim 17,
OSAKI discloses wherein, when a new version of a setting file does not exist in an application environment, the processor is further configured to read a setting content from an old version of the setting file existing in the application environment, copy the new version of the setting file existing in an upper-level layer of the middle layer to the application environment, and set the setting content in the copied new version of the setting file (OSAKI [0022] e.g. new container version).
13. With respect to claim 19,
OSAKI discloses wherein the processor is further configured to manage the middle image in a multi-version configuration during a transition period (OSAKI [0022], [0053] e.g. period) in which the control system is migrated, and use both an old middle image and a new middle image when the control system as a migration destination is operated.
14. With respect to claim 20,
ZHANG discloses wherein the processor is further configured to store a system image including the middle image subjected to the compatibility processing in a storage unit when the control system is terminated (ZHANG [0095] e.g. deleted).
15. Claim 10 is same as claim 1 and is rejected for the same reasons as applied hereinabove.
16. Claims 3-8 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG in view of OSAKI, and further in view XU.
17. With respect to claim 3
OSAKI further discloses wherein each layer in the hierarchical structure corresponds to a different version of the control system and the processor searches from the uppermost-level layer to the lowermost-level layer to select the middle image and perform the compatibility processing (OSAKI [0018], [0026]).
Although ZHANG and OSAKI combination substantially teaches the claimed invention, they do not explicitly indicate wherein, when an activation mode is an image update operation, the processor is further configured to mount the middle image and an application data file for migration picked up from the application environment in a designated mounting destination, stores a system image including the middle image subjected to the compatibility processing by the processor in a storage unit by start-up of the control system, and constitutes the file system on a basis of the system image read from the storage unit when the activation mode is a normal operation.
XU teaches the limitations by stating wherein, when an activation mode is an image update operation, the processor is further configured to mount the middle image and an application data file for migration picked up from the application environment in a designated mounting destination, stores a system image including the middle image subjected to the compatibility processing by the processor in a storage unit by start-up of the control system, and constitutes the file system on a basis of the system image read from the storage unit when the activation mode is a normal operation (XU [0035] – [0036] e.g. [0035] The rebuild agent 118 may use the service meta-app 122A to rebuild the source provider service environment in the target provider environment 106. For example, in these and other embodiments, the rebuild agent 118 may generally analyze the service meta-app 122 A to identify internal dependencies and configurations and environmental context and configurations of the service114A. The identified information may then be used by the rebuild agent 118 to fetch the service image124 A, any of the dependency images 124B corresponding to internal dependencies of the service 114A and to provide the service image 124 A with the identified environmental context and configuration. The configured service image 124 A may then be started up in the target provider environment 106 as the service 114B. [0036] Some service migration procedures may implement a time- and/or resource-intensive graph-matching algorithm to find a best match image having a structure that is close to the structure of an image of the service 1 14A in the source provider environment 104. In contrast, some embodiments described herein can identify and locate a particular image of the service 114A, e.g., the service image 124A, using the pointer in the corresponding service meta-app 122 A, without performing a time- and/or resource- intensive matching algorithm).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of ZHANG, OSAKI and XU, to overcome the difficulties associated with rebuilding the application or otherwise migrating the application due to compatibility issues between the source and target provider environments may dissuade the user from migrating the application to the target provider environment even though it might otherwise be beneficial, e.g., in terms of cost and/or performance, to the user to migrate the application to the target provider environment (XU [0004]).
18. With respect to claim 4,
XU further discloses wherein the user interface ensures compatibility between a processing operation of the middle layer and the application environment used in the control system as a migration source and a processing operation of the middle layer and the application environment used in the control system as a migration destination (XU [0034] – [0037] e.g. [0035] The rebuild agent 118 may use the service meta-app 122A to rebuild the source provider service environment in the target provider environment 106. For example, in these and other embodiments, the rebuild agent 118 may generally analyze the service meta-app 122 A to identify internal dependencies and configurations and environmental context and configurations of the service114A. The identified information may then be used by the rebuild agent 118 to fetch the service image124 A, any of the dependency images 124B corresponding to internal dependencies of the service 114A and to provide the service image 124 A with the identified environmental context and configuration. The configured service image 124 A may then be started up in the target provider environment 106 as the service 114B. [0036] Some service migration procedures may implement a time- and/or resource-intensive graph-matching algorithm to find a best match image having a structure that is close to the structure of an image of the service 1 14A in the source provider environment 104. In contrast, some embodiments described herein can identify and locate a particular image of the service 114A, e.g., the service image 124A, using the pointer in the corresponding service meta-app 122 A, without performing a time- and/or resource- intensive matching algorithm).
19. With respect to claim 5,
ZHANG further discloses
the processor is further configured to select the middle image to be searched for in order of a latest version (ZHANG [0003], [0010] – [0013], [0028] – [0029], [0032] - [0034], [0045], [0070] – [0076], [0081] – [0096] e.g. version; [0010] In some implementations, generation of a new version of the file that includes content associated with the portion of the file may include the content management platform retrieving a plurality of bytes from the file that correspond to the portion corresponding to the content. The content management platform may then generate one or more new bytes representing the content associated with the portion wherein the one or more new bytes are formatted based upon the third-party application format. The content management platform may generate the new version of the file that includes the plurality of bytes from the file and the one or more new bytes that represent the content associated with the portion corresponding to the received content. [0011] In some implementations, the content management platform may receive a request to store a second version of the file, where the second version of the file contains updated content (e.g. new/updated comments). The content management platform may then extract the new content from the second version of the file and merge the new content with existing content from the currently stored version of the file. The content management platform may then store the second version of the file and the merged content within the content management platform.),
determine whether compatibility processing is necessary for the middle image selected, and
perform the compatibility processing on the middle image for which the compatibility processing is determined to be necessary (ZHANG [0027], [0029], [0032], [0044], [0062], [0071] – [0072], [0081], [0083] e.g. compatible; [0062] The associated collaborative document may be any type of image file that is compatible with a third-party application image viewer).
20. With respect to claim 6,
XU further discloses wherein the processor is further configured to search the middle layer for an execution file activated by start- up of the control system, loads the execution file subjected to the compatibility processing into a merge layer in which the user interface is constituted, then searches the middle layer for a setting file of the application, and opens the setting file subjected to the compatibility processing in the merge layer (XU [0035] – [0036] e.g. [0035] The rebuild agent 118 may use the service meta-app 122A to rebuild the source provider service environment in the target provider environment 106. For example, in these and other embodiments, the rebuild agent 118 may generally analyze the service meta-app 122 A to identify internal dependencies and configurations and environmental context and configurations of the service114A. The identified information may then be used by the rebuild agent 118 to fetch the service image124 A, any of the dependency images 124B corresponding to internal dependencies of the service 114A and to provide the service image 124 A with the identified environmental context and configuration. The configured service image 124 A may then be started up in the target provider environment 106 as the service 114B. [0036] Some service migration procedures may implement a time- and/or resource-intensive graph-matching algorithm to find a best match image having a structure that is close to the structure of an image of the service 1 14A in the source provider environment 104. In contrast, some embodiments described herein can identify and locate a particular image of the service 114A, e.g., the service image 124A, using the pointer in the corresponding service meta-app 122 A, without performing a time- and/or resource- intensive matching algorithm).
21. With respect to claim 7,
ZHANG further discloses wherein, when a new version of a setting file exists in the application environment, the processor is further configured to open the new version of the setting file, and when a new version of a setting file does not exist in the application environment, the processor reads a setting content from an old version of the setting file existing in the application environment, copies a new version of the setting file existing in an upper-level layer of the middle layer to the application environment, sets the setting content in the copied new version of the setting file, and opens the new version of the setting file in a merge layer in which the user interface is constituted (ZHANG [0003], [0010] – [0013], [0028] – [0029], [0032] - [0034], [0045], [0070] – [0076], [0081] – [0096] e.g. version; [0010] In some implementations, generation of a new version of the file that includes content associated with the portion of the file may include the content management platform retrieving a plurality of bytes from the file that correspond to the portion corresponding to the content. The content management platform may then generate one or more new bytes representing the content associated with the portion wherein the one or more new bytes are formatted based upon the third-party application format. The content management platform may generate the new version of the file that includes the plurality of bytes from the file and the one or more new bytes that represent the content associated with the portion corresponding to the received content. [0011] In some implementations, the content management platform may receive a request to store a second version of the file, where the second version of the file contains updated content (e.g. new/updated comments). The content management platform may then extract the new content from the second version of the file and merge the new content with existing content from the currently stored version of the file. The content management platform may then store the second version of the file and the merged content within the content management platform.).
22. With respect to claim 8,
ZHANG further discloses the processor opens the comprehensive file and loads the execution file into the merge layer (ZHANG [0011], [0029], [0032] e.g. [0011] In some implementations, the content management platform may receive a request to store a second version of the file, where the second version of the file contains updated content (e.g. new/updated comments). The content management platform may then extract the new content from the second version of the file and merge the new content with existing content from the currently stored version of the file. The content management platform may then store the second version of the file and the merged content within the content management platform).
23. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over ZHANG in view of XU and OSAK, and further in view of Kimse.
24. With respect to claim 9
Although ZHANG, OSAK and XU combination substantially teaches the claimed invention, they do not explicitly indicate wherein, when the middle image subjected to the compatibility processing has a defect, the processor is further configured to acquire an old version of the middle image and perform rollback.
Kimse teaches the limitations by stating wherein, when the middle image subjected to the compatibility processing has a defect, the processor is further configured to acquire an old version of the middle image and perform rollback (Kimse [0018], [0022], [0128] – [0157] e.g. Provided that the modified build passes tests at the various integration and testing environments, it may be deployed to one or more cloud environments as a new build. If the new build is found to be defective or to include bugs, it can be rolled back by reverting to a previous version of the build. [0022] Also, a cloud application with container-implemented executables and/or libraries may not be independent of the schema or schemas of the persistencies used by the application. Accordingly, updating the application at the cloud may include performing a data migration at one or more cloud persistencies to make those persistencies consistent with the upgraded application. Such data migrations may be time and resource-intensive and, therefore, difficult to roll back in the event of a bug or other error.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of ZHANG. OSAK, XU and Kimse, to overcome the difficulties associated with rebuilding the application or otherwise migrating the application due to compatibility issues between the source and target provider environments may dissuade the user from migrating the application to the target provider environment even though it might otherwise be beneficial, e.g., in terms of cost and/or performance, to the user to migrate the application to the target provider environment (XU [0004]).
25. Claims 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG in view of OSAKI, and further in view Yeung et al (US 20110307848 A1 hereinafter, “Yeung”).
26. With respect to claim 11
Although ZHANG and OSAKI combination substantially teaches the claimed invention, they do not explicitly indicate wherein the processor is further configured to automatically generate a wrapper image for old version compatibility when an application programming interface of a new version of a dynamic link library file in the middle image is changed.
Yeung teaches the limitations by stating wherein the processor is further configured to automatically generate a wrapper image for old version compatibility when an application programming interface of a new version of a dynamic link library file in the middle image is changed (Yeung Abstract, [0008], claim 18 e.g. … Because some formal verification tools cannot handle the complexity often associated with sequential equivalence checking at the top level of a circuit, the modified IC design may be instantiated into a number of different design versions, each having different levels of modification complexity. In addition, the reference IC design and the modified versions may be decomposed into a datapath and control path. The reference IC design and each of the modified IC design versions may also use wrappers to encapsulate various levels of hierarchy of the logic. Lastly, rather than having to verify each of the modified versions back to the reference IC design, the equivalence checking may be performed between each modified IC design version and a next modified IC design version having a greater modification computational complexity. [0008] Various embodiments of a method for formally verifying a modified IC design are disclosed. Broadly speaking, a method for preparing an IC design that has been modified to be formally verified with a reference IC design is contemplated. Because many verification tools cannot handle the complexity often associated with sequential verification at the top level of a circuit, the modified IC design may be instantiated into a number of different design versions, each having different levels of modification complexity. In addition, the reference IC design and the modified versions may be decomposed into a datapath and control path. The reference IC design and each of the modified IC design versions may also use wrappers to encapsulate various levels of hierarchy of the logic. Lastly, rather than having to verify each of the modified versions back to the reference IC design, the sequential equivalence checking may be performed between each modified IC design version and a next modified IC design version having a greater modification computational complexity. [claim 18] wrapper file).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of ZHANG, OSAKI and Yeung, to predict IO load and prevent application performance failure (OSAKI [0004]).
27. With respect to claim 18,
Yeung further discloses wherein the processor is further configured to load a wrapper file instead of a new version of a dynamic link library file when confirming presence of the wrapper file in the hierarchical structure (Yeung Abstract, [0008], claim 18 e.g. … Because some formal verification tools cannot handle the complexity often associated with sequential equivalence checking at the top level of a circuit, the modified IC design may be instantiated into a number of different design versions, each having different levels of modification complexity. In addition, the reference IC design and the modified versions may be decomposed into a datapath and control path. The reference IC design and each of the modified IC design versions may also use wrappers to encapsulate various levels of hierarchy of the logic. Lastly, rather than having to verify each of the modified versions back to the reference IC design, the equivalence checking may be performed between each modified IC design version and a next modified IC design version having a greater modification computational complexity. [0008] Various embodiments of a method for formally verifying a modified IC design are disclosed. Broadly speaking, a method for preparing an IC design that has been modified to be formally verified with a reference IC design is contemplated. Because many verification tools cannot handle the complexity often associated with sequential verification at the top level of a circuit, the modified IC design may be instantiated into a number of different design versions, each having different levels of modification complexity. In addition, the reference IC design and the modified versions may be decomposed into a datapath and control path. The reference IC design and each of the modified IC design versions may also use wrappers to encapsulate various levels of hierarchy of the logic. Lastly, rather than having to verify each of the modified versions back to the reference IC design, the sequential equivalence checking may be performed between each modified IC design version and a next modified IC design version having a greater modification computational complexity. [claim 18] wrapper file).
28. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over ZHANG in view of OSAKI, and further in view Zhang et al (US 20210158539 A1 hereinafter, “Zhang 539”).
29. With respect to claim 13
Although ZHANG and OSAKI combination substantially teaches the claimed invention, they do not explicitly indicate wherein the processor is further configured to create a new middle difference that is a difference between an old middle Image of a lower-level layer and a new middle image of an upper-level layer in the hierarchical structure.
Zhang 539 teaches the limitations by stating wherein the processor is further configured to create a new middle difference that is a difference between an old middle Image of a lower-level layer and a new middle image of an upper-level layer in the hierarchical structure (Zhang 539 [0031] e.g. difference).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of ZHANG, OSAKI and Zhang 539, to predict IO load and prevent application performance failure (OSAKI [0004]).
30. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over ZHANG in view of OSAKI, and further in view YANG et al (CN 120010750 A hereinafter, “YANG”).
31. With respect to claim 14
Although ZHANG and OSAKI combination substantially teaches the claimed invention, they do not explicitly indicate wherein the processor is further configured to set the middle image and an application data file for migration in designated mounting points on a basis of a mounting point management table.
YANG teaches the limitations by stating wherein the processor is further configured to set the middle image and an application data file for migration in designated mounting points on a basis of a mounting point management table (YANG page 10 e.g. determining a mounting table corresponding to the data to be migrated; updating the source mounting point as the target mounting point by the mounting table corresponding to the data to be migrated).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of ZHANG, OSAKI and YANG, to predict IO load and prevent application performance failure (OSAKI [0004]).
Response to Argument
32. Applicant’s remarks and arguments presented on 4/6/2026 have been fully considered but they are moot in view of the new grounds of rejection presented in this office action.
Conclusion
33. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098. The fax and phone numbers for the organization where this application or proceeding is assigned is 571-273-8300.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist whose telephone number is 571-272-2100.
/SYLING YEN/Primary Examiner, Art Unit 2166
April 14, 2026
Prosecution Insights