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 .
This action is responding to application papers dated 3/14/2024.
Claims 1-20 are pending in the application.
The information disclosure statement filed on 3/14/2024 has been considered.
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-4, 6, 8-11, 13, 15-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over De Smet et al. (CN112667268, hereafter De Smet) in view of Beavers et al. (US20140033188, hereafter Beavers) and Chen et al. (US 20230185556, hereafter Chen).
1. A system comprising: a processing device; and a non-transitory memory comprising instructions that are executable by the processing device for causing the processing device to: generate a first version of a binary large object (BLOB) file indicating first metadata for each file of a first version of an image for an operating system; generate a second version of the BLOB file indicating second metadata for each file of a second version of the image, wherein the second version comprises a plurality of new files associated with an update to the operating system (De Smet, see at least page 2, the firmware is divided into a plurality of binary large objects (blob), each blob has associated blob version; each blob version is associated with a firmware version; … if the compatibility tree blob version is more new than the current blob version, then each blob in the remaining blob is included on the upgrade list; transmitting data comprising a blob compatibility list in response to a request from the client network node to the first blob update version, the blob compatibility list comprising the version of the remaining blob; fig. 2 and associated texts, blob identifier and a version; Fig. 6 and associated texts, combability tree for upgrading blobs from versions to new blobs of new version numbers; [Note that the blog versions indicate the versions/identifiers of the blobs (metadata)]).
De Smet does not explicitly teach the firmware is an operating system to be updated. Beavers teaches an OS update (Beavers, see at least abstract, updates to device firmware, operating system (OS); [0010], diffs are constructed using the differences that exist between the image of the update VHD and one or more versions of the OS and/or application stack corresponding to the local hard drive image of each device). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Beaver’s OS update with De Smet’s firmware update to modify De Smet’s system to combine the OS update as taught by Beavers, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to update. Combining Beaver’s functionality with that of De Smet results in a system that allows to apply the update to an OS. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to provide an updated version of an OS (Beavers, see at least abstract, updates to device firmware, operating system (OS); [0010], diffs are constructed using the differences that exist between the image of the update VHD and one or more versions of the OS and/or application stack corresponding to the local hard drive image of each device).
De Smet further teaches execute the update to the operating system by a system for the operating system, the second version of the image of the operating system using the second metadata from the second version of the BLOB file (De Smet, see at least FIG. 7 D and associated texts, an example upgrade process 380 based on an initial upgrade list generated from the compatibility tree 360. … a blob version which is the same as the currently installed version or is older than the currently installed version is removed from the list … The upgrade list may be stored in a non-volatile memory. Subsequently, the process sequentially performs upgrade list from left to right, and a blob is installed at one time. …The network client node may then be restarted; Fig. 5 and associated test, the node can still operate normally after any blob upgrade and reboot … upgrading each blob according to the upgrading order of the blob. and restarting the client after each blob is upgraded).
De Smet and Beavers do not explicitly teach remounting by a file system. Chen teaches remounting by a file system (Chen see at least [0115] when resource migration occurs on the cloud phone used by the user, the cloud phone before migration may be stopped first, and the cloud phone after migration may remount the network shared file, to quickly implement cloud phone resource migration. Because the entire migration process is based on mounting of the network shared file). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Chen’s remounting by a file system with Beaver’s OS update and De Smet’s firmware update to modify De Smet’s system to combine the OS update as taught by Beavers, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to update. Combining Chen’s functionality with that of De Smet and Beavers results in a system that allows to remount by a file system. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to dynamically change file options offering quick update (read-only (Chen see at least [0115] when resource migration occurs on the cloud phone used by the user, the cloud phone before migration may be stopped first, and the cloud phone after migration may remount the network shared file, to quickly implement cloud phone resource migration. Because the entire migration process is based on mounting of the network shared file).
Per claim 2:
De Smet in view of beavers further teaches: identify a first set of services having access to the plurality of new files subsequent to execution of the update restart execution of the first set of services subsequent to remounting the second version of the image of the operating system ((De Smet, see at least FIG. 4-7 and associated texts, Subsequently, the process sequentially performs upgrade list from left to right, and a blob is installed at one time. In step 386, the blob Av (i + 1) is downloaded and removed from the update list updated in the non-volatile memory. The network client node may then be restarted).
De Smet and Beavers do not explicitly teach stopping execution of the first set of services prior to remounting the second version of the image of the operating system. Chen teaches stopping execution of services prior to remounting (Chen see at least [0115] when resource migration occurs on the cloud phone used by the user, the cloud phone before migration may be stopped first, and the cloud phone after migration may remount the network shared file, to quickly implement cloud phone resource migration. Because the entire migration process is based on mounting of the network shared file). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Chen’s stop and remount functions with Beaver’s OS update and De Smet’s firmware update to modify De Smet’s system to combine the OS update as taught by Beavers, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to update. Combining Chen’s functionality with that of De Smet and Beavers results in a system that allows to stop an execution of services before remounting for migration. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to stop execution of services and then remount files for data integrity or reliability (Chen see at least [0115] when resource migration occurs on the cloud phone used by the user, the cloud phone before migration may be stopped first, and the cloud phone after migration may remount the network shared file, to quickly implement cloud phone resource migration. Because the entire migration process is based on mounting of the network shared file).
3. The system of claim 2, wherein the memory further comprises instructions that are executable by the processing device for causing the processing device to: identify a second set of services lacking access to the plurality of new files subsequent to execution of the update; and continue execution of the second set of services while remounting the second version of the image of the operating system (De Smet, see at least Fig. 4 and associated texts, upgrade list contains only one node Avi, so it can continue to download and continue to upgrade …Because the compatibility tree is not completed, the method then continues the step of Bvj, Cvk, Dvl, so as to construct other sub-node of Avi in the compatibility tree …The OTA client 470 continues to construct the compatibility tree according to the compatibility list in the OTA file…. until the leaf node of the compatible tree is identified …The method 450 continues until the compatibility tree is constructed by identifying all leaf nodes; Fig. 5 and associated texts, Note that if the OTA client is running the old version blob, the OTA client will continue to upgrade the blob).
4. The system of claim 1, wherein the memory further comprises instructions that are executable by the processing device for causing the processing device to, prior to generating the first version of the BLOB file: mount, by the file system, the first version of the image of the operating system (De Smet, see at least Fig. 4 and associated texts the OTA client 420 has run all blob versions or the new blob version of the blob version in the compatibility list … If the OTA client is running the old version blob, the OTA client will continue to upgrade the blob. If one version of the blob versions listed in the compatibility list is not supported, the OTA client will verify the compatibility list and may terminate the process. Once all blob versions in the upgrade list are running on the OTA client, the needed blob version (Avi) can be upgraded; page 2, the firmware is divided into a plurality of binary large objects (blob) …if the compatibility tree blob version is more new than the current blob version, then each blob in the remaining blob is included on the upgrade list; transmitting data comprising a blob compatibility list in response to a request from the client network node to the first blob update version, the blob compatibility list comprising the version of the remaining blob; fig. 2 and associated texts, blob identifier and a version; Fig. 6 and associated texts, combability tree for upgrading blobs from versions to new blobs of new version numbers; [Note that an existing firmware needs to be running (mounted), so its files can be accessed, updated]).
Per claim 6:
De Smet does not explicitly teach executing the update to the operating system while running the operating system. Beavers further teaches executing the update to the operating system while running the operating system (Beavers, see at least [0082] the ZTM performs updates while already booted into a first drive or VHD on the device by mounting a second drive or VHD (having either the same or different version of the OS and/or application stack as the first drive or VHD; [0083] devices do not need to be taken offline or otherwise inconvenience the user during updates, since updates are performed while the device is booted into a first image of the OS and/or application stack by simply mounting and manipulating the state of a second or alternate image of the OS and/or application stack. A simple mounting and reboot into the newly updated OS and/or application stack then runs the new version of the OS and/or application stack without further manipulation or changes to any hard drive or VHD. Consequently, it should be understood that while running any version of the OS and/or application stack, the device can separately mount one or more copies of any version of the OS and/or application stack which can then be updated to the desired OS and/or application stack using corresponding manifest files and diffs; [0097]). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Beaver’s update while running a program with De Smet’s firmware update combined with Chen’s remounting to modify De Smet’s system to combine the OS update as taught by Beavers, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to update. Combining Beaver’s functionality with that of De Smet and Chen results in a system that allows to apply the update to an program while running the program. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to perform an update without causing inconvenience to a user (Beavers, see at least [0082] the ZTM performs updates while already booted into a first drive or VHD on the device by mounting a second drive or VHD (having either the same or different version of the OS and/or application stack as the first drive or VHD; [0083] devices do not need to be taken offline or otherwise inconvenience the user during updates, since updates are performed while the device is booted into a first image of the OS and/or application stack by simply mounting and manipulating the state of a second or alternate image of the OS and/or application stack. A simple mounting and reboot into the newly updated OS and/or application stack then runs the new version of the OS and/or application stack without further manipulation or changes to any hard drive or VHD. Consequently, it should be understood that while running any version of the OS and/or application stack, the device can separately mount one or more copies of any version of the OS and/or application stack which can then be updated to the desired OS and/or application stack using corresponding manifest files and diffs; [0097]).
Per claims 8-11, 13, 15-18 and 20, they are the method and medium versions of claims 1-4 and 6 respectively, and are rejected for the same reasons set forth in connection with the rejection of claims 1-4 and 6 above.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over De Smet in view of Beavers, Chen and Charlet et al. (US 20200104386, hereafter Charlet).
Per claims 5:
De Smet, Beavers and Chen do not explicitly teach the first metadata or the second metadata comprising a location of the file accessing a file via a first location indicated by the first metadata to a second location indicated by the second metadata. Charlet teaches such a metadata comprising a location of a file (Charlet, see at least [0024] Conversions of BLOB mappings or re-mappings based on a value of a control field within the BLOB are typically able to produce human readable values as needed because the metadata and field data have been input correctly (i.e., no input errors) and have been mapped to a proper location. However, errors (e.g., incorrect structural metadata or an incorrect overlay of the BLOB to the metadata (location)) or data corruption can be introduced to the value the control field by a user when creating or importing data structure information into the structural metadata. Accordingly, when attempting to convert the bytes from the BLOB using field metadata associated with a particular location in the BLOB; [0025]. The user can interactively move the structural metadata to any location within a BLOB, as well as automatically convert bytes for each field associated with the BLOB …) the structural metadata in the context of a location within a BLOB, which can be used to materialize structural metadata for use by a software system to produce a human readable output). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Charlet’s location metadata with Beaver’s OS update, Chen’s remounting and De Smet’s firmware update to modify De Smet’s system to combine the location metadata as taught by Charlet, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to update or data processing. Combining Charlet’s functionality with that of De Smet, Chen and Beavers results in a system that allows to include a location information. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to map the update to a proper location (Charlet, see at least [0024] Conversions of BLOB mappings or re-mappings based on a value of a control field within the BLOB are typically able to produce human readable values as needed because the metadata and field data have been input correctly (i.e., no input errors) and have been mapped to a proper location. However, errors (e.g., incorrect structural metadata or an incorrect overlay of the BLOB to the metadata (location)) or data corruption can be introduced to the value the control field by a user when creating or importing data structure information into the structural metadata. Accordingly, when attempting to convert the bytes from the BLOB using field metadata associated with a particular location in the BLOB; [0025]. The user can interactively move the structural metadata to any location within a BLOB, as well as automatically convert bytes for each field associated with the BLOB …) the structural metadata in the context of a location within a BLOB, which can be used to materialize structural metadata for use by a software system to produce a human readable output).
De Smet in view of Beavers, Chen and Charlet further teaches the first metadata or the second metadata comprises, for each file of the operating system and wherein the memory further comprises instructions that are executable by the processing device for causing the processing device to execute the update to the operating system by: switching from accessing a file via a first location indicated by the first metadata of the first version of the BLOB file to a second location indicated by the second metadata of the second version of the BLOB file (De Smet, see at least FIG. 7 D and associated texts, an example upgrade process 380 based on an initial upgrade list generated from the compatibility tree 360. … a blob version which is the same as the currently installed version or is older than the currently installed version is removed from the list … The upgrade list may be stored in a non-volatile memory. Subsequently, the process sequentially performs upgrade list from left to right, and a blob is installed at one time. …The network client node may then be restarted; Fig. 5 and associated test, the node can still operate normally after any blob upgrade and reboot … upgrading each blob according to the upgrading order of the blob. and restarting the client after each blob is upgraded; [Note that the currently installed old version is removed and the new version is installed with updated blobs, therefore using the new version to complete the update process makes it the active firmware (mounting) after the reboot).
Per claims 12 and 19, they are the method and medium versions of claims 5 respectively, and are rejected for the same reasons set forth in connection with the rejection of claim 5 above.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over De Smet in view of Beavers, Chen and Kinsburskiy et al. (US10891153, Hereafter Kinsburskiy).
Per claim 7:
De Smet, Beavers and Chen do not explicitly teach wherein the file system has a same mount identifier used by the operating system prior to execution of the update and subsequent to execution of the update. Kinsburskiy teaches wherein the file system has a same mount identifier used by the operating system prior to execution of the update and subsequent to execution of the update (Kinsburskiy, see at least fig. 1-3 and associated texts, the file system switcher 310 can compare mount IDs … If the mount IDs are the same, then the file system switcher 310 can identify the corresponding resources that need to be replaced according to the algorithm described herein). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Kinsburskiy’s same mount identifier with De Smet’s firmware update to modify De Smet’s system to combine the same mount ID as taught by Kinsburskiy, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to update or data processing. Combining Kinsburskiy’s functionality with that of De Smet, Beavers, and Chen results in a system that allows to use the same mount identifier. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to provide transparent, flexible access to a shared resource (Kinsburskiy, see at least fig. 1-3 and associated texts, the file system switcher 310 can compare mount IDs … If the mount IDs are the same, then the file system switcher 310 can identify the corresponding resources that need to be replaced according to the algorithm described herein).
Per claim 14, it is the method version of claim 7, and is rejected for the same reasons set forth in connection with the rejection of claim 7 above.
Examiner’s Note
The Examiner has pointed out particular references contained in the prior art of record within the body of this action 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. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20110173601 is related to differential updating of an operating system in a client device;
US20210240468 is related to a microcode update system;
US20200133704 is related to a microcode update from a guest operating system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 8 -5pm; week 2: Tu-F 8-5pm.
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.
/INSUN KANG/ Primary Examiner, Art Unit 2193